EGit/Proposal

Introduction

The EGIT plugin is a Team provider for Git (a.k.a. "Stupid Content Tracker", http://git.or.cz).

Git is the version control system originally developed for the Linux kernel by Linus Torvalds, and is now a general Software Configuration Management (SCM) and Distributed Version Control System (DVCS) used by many other projects, both for open source and commercial development. Git is a fast distributed SCM, which means every developer has a full copy of all history of every revision of the code making queries against the history very fast and versatile. The storage model also means most operations are ten to a hundred times faster than with traditional centralized SCMs such as CVS or Subversion. The integrity of the code is protected through the use of secure hashes of content and history, plus optional GPG(PGP)-signing of tags.

Project Goal

The goal is to implement a Team provider for the Git SCM for eclipse.

Project Scope

The project will implement a significant amount of functionality of Git in Java for use with primarily Eclipse, although the intention is that core functionality shall be usable outside the Eclipse platform. The limit to what can be implemented in Java is to be discovered. Core functionality is already implemented so we think that most if not all can be implemented in Java without significant performance loss.

Performance is a big deal with git. It affects what can be done by being so much faster. Things that couldn't be done because of time constraints are now possible. These things like very fast checkouts, branching, branch switching, merging, tagging, software archeology and synchronization. Merge speed is probably the most important feature.

The Git plugin shall be fully compatible with the native version so both can be used on the same checkout out repository.

Project description

The Git team provider will provide the ability to do all everyday task in a Git work flow from inside Eclipse.

• Initial project setup: The plugin will allow user to create new Git repositories.

• Importing existing code: Existing local Git repositories as well as remote repository can be imported. Remote repositories are imported by `cloning' them resulting in a local copy.

• Replicating repositories: It shall be possible to distribute local version to other repositories through "push" operations as well as patches distributed by electronic mail. Receiving content shall be possible by fetching content via the git protocol (raw, ssh and http based) and via e-mailed patches directly from mailboxes, file or clipboard. "Bundles" shall also be supported.

• Quickdiff against any version shall be supported.

• Comparing any versions shall be supported.

• Producing git-format patches to the clipboard shall be supported.

• Selective commit (using the Quickdiff markers) shall be supported

• Merge shall be supported

• Cherry picking shall be supported

• Re-base of branches shall be supported. This includes splitting, reordering and squashing (alternate term not to be confused with the normal meaning of "merge" in SCM terminology).

• Branch switching, committing, amending commits and reset shall be supported.

• Partial checkouts (currently not a native Git feature) shall be possible.

• Some form of synchronization with CVS. At least export to CVS, like git cvsexportcommit.

Perspectives

A Git perspective will be provided for browsing repositories before importing Git projects.

Extension points

Quickdiff must be enhanced to allow selective committing.

Views

A history viewer with graphical presentation of history and access for compare editors.

Repository browser

An explorer for examining Git repositories not connected to an eclipse project. Importing projects shall be possible from here.

Extensions to existing functionality

Team provider Resource decorators Quickdiff provider

CVS export

Git commits shall be exportable to a CVS repository with the same structure. CVS import is a much harder problem where no perfect solution exists.

Code contributions

The existing code base shall be re-licensed under the EPL (this has already been approved by current comitters).

Development plan

Project Lead

Shawn Pearce

Potential Committers

• Robin Rosenberg
• Shawn Pearce
• Philippe Ombredanne

Milestones

Some functionality already exists, but there is no real plan at the moment for lack of committed resources. A rough idea of prioritization is

Already done:

• Connect to/create repositories for exiting projects
• Create branches
• Commit
• Quickdiff against current revision
• Resources decorators for tracked and modified resources as well as repository state
• Basic compare of revisions

Underway:

• Cloning and updating from remote repositories

Future:

• Bisecting
• Partial commits (i.e. committing partial changes)
• Comprehensive handling of different character encodings in filenames and comments.
• CRLF handling (unless we consider it unneeded)
• Bugfixes for existing code
• Formatting code for patch submission through e-mail
• Apply patch
• Rename/Copy tracking in compare revisions
• Blame (annotate)
• Merge
• Rebase
• External repository browser
• Repacking (this a really a core Git feature and the one that can be really hard or impossible to perform in Java).
• Rename tracking is an on-demand feature in git. Git does not record such information, it discovers it from content. The tight data structures in git makes implementing this in real time possible, but could still be a challenge.

References

• Git - The SCM we want to provide an interface through. http://git.or.cz

• Mylyn - Task based IDE. Git is very much about simplifying the delivery of well defined solutions to specific problems in an orderly fashion so it seems both projects have similar objectives. I have no idea about what git integration with Mylyn would look like for lack of Mylyn knowledge.