Jump to: navigation, search

Difference between revisions of "Git for Committers"

(36 intermediate revisions by 10 users not shown)
Line 1: Line 1:
 
= Background =
 
= Background =
* {{bug|257706}} Host a git repository on Eclipse Foundation servers, support git as the repository of Eclipse projects
+
 
 +
== Motivation ==
 +
 
 +
DVCS make cheap branches a first class concept.  When everyone has their own branch / fork it's up to the VCS to make local changeset management easy and the merge process as painless as possible.
 +
 
 +
This guide illustrates how you might use git to increase productivity when developing Eclipse. Even committers with access to the centralized repository will benefit.  After all a committer can't (shouldn't!) commit work-in-progress to a repo relied on by millions of users.  git makes the process of tracking and merging upstream changes painless, and allows quick and easy patch regeneration for bugzilla review.
 +
 
 +
The guide does not aim to give an exhaustive overview of the commands and how they work. There is large body of existing documentation under [[#Reference]].
 +
 
 +
== Related ==
 
* [[EGit/Proposal]]
 
* [[EGit/Proposal]]
 +
 +
== Bugs ==
 +
* {{bug|257706}} Host a git repository on Eclipse Foundation servers, support git as the repository of Eclipse projects
 +
** [https://bugs.eclipse.org/bugs/show_bug.cgi?id=257706#c63 bug 257706#c63] Mike M. on potential problems with git at the Foundation
 +
* {{bug|249745}} Eclipse Repository Best Practices
  
 
= Setting up git =
 
= Setting up git =
* How to set up a local git repository as a committer
+
 
* How to import from Eclipse CVS
+
== Easy-setup ==
** http://manandbytes.wordpress.com/2008/12/23/how-to-import-eclipseorgs-cvs-into-git-with-git-cvsimport/
+
 
** Any additional notes to that?
+
Has someone already imported the repository for you? If so clone or fork theirs! Creating the repository from scratch is straightforward, but beware the initial checkout is very time consuming. (It's also not very friendly to the Eclipse CVS servers; git has to reconstruct the individual commits and checkout each changeset individually...)
* Important Commandline Commands to push etc
+
(See [[#Known_git_repositories_for_Eclipse_projects]]).
** Something along the lines of [http://ketan.padegaonkar.name/2009/01/24/using-mercurial-with-eclipse-cvs.html Ketan's blog for Mercurial]
+
 
 +
Cloning a repository is as easy as:
 +
 
 +
<tt>[http://www.kernel.org/pub/software/scm/git/docs/git.html git] [http://www.kernel.org/pub/software/scm/git/docs/git-clone.html clone] <repo_url> my_checkout_dir_name</tt>
 +
 
 +
e.g.
 +
<tt> git clone git://github.com/jamesblackburn/eclipse-core-resources-tests.git org.eclipse.core.tests.resources</tt>
 +
 
 +
== Importing a repo ==
 +
 
 +
The process of creating a repository is the same whether you're an existing committer or not. 
 +
 
 +
=== Tracking only your own changes ===
 +
If you're only interested in your own changes and/or don't care about importing existing commit history from a legacy repository, you can just tell git to start tracking changes in a specific directory tree.
 +
Turn any directory into a versioned repository with the sequence:
 +
 
 +
<tt> git [http://www.kernel.org/pub/software/scm/git/docs/git-init.html init] <br/>
 +
git [http://www.kernel.org/pub/software/scm/git/docs/git-add.html add] .  <br/>
 +
git [http://www.kernel.org/pub/software/scm/git/docs/git-commit.html commit] </tt>
 +
 
 +
=== Importing from CVS ===
 +
 
 +
<tt>
 +
git [http://www.kernel.org/pub/software/scm/git/docs/git-cvsimport.html cvsimport] -v -C eclipse-core-resources -d :pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse -r cvs org.eclipse.core.resources
 +
</tt>
 +
 
 +
This command creates a new git repository importing all the history, in this case, from the ''org.eclipse.core.resources'' repository.
 +
 
 +
This commands says: ''import'' the org.eclipse.core.resources module into a git repository in the directory ('''-C''') eclipse-core-resources.  The '''-r''' switch says to store the loaded repository data under the ''cvs'' remote.  A remote is like a git branch except you ''never'' checkout a remote directly. You'll create your own branches based on remote versions. The remote branches must be kept clean for when you next '''[http://www.kernel.org/pub/software/scm/git/docs/git-fetch.html fetch]''' updates from the remote.
 +
 
 +
With that one command you now have a fully-fledged repository waiting for you. Take a look:
 +
 
 +
<tt>
 +
cd eclipse-core-resources<br/>
 +
git [http://www.kernel.org/pub/software/scm/git/docs/git-branch.html branch] -a<br/>
 +
git [http://www.kernel.org/pub/software/scm/git/docs/git-log.html log]<br/>
 +
</tt>
 +
 
 +
''git'' '''branch -a''' will show all the branches -- you'll see this contains all the upstream branches, potentially a lot!  You'll see that you're currently sitting in ''master'' which cvsimport has created for you tracking the ''cvs/master'' remote branch. ''git'' '''log''' shows you the full imported commit history on this branch.
 +
 
 +
== Staying fresh ==
 +
 
 +
<tt>
 +
git [http://www.kernel.org/pub/software/scm/git/docs/git-cvsimport.html cvsimport] '''-i''' -v -C eclipse-core-resources -d :pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse -r cvs org.eclipse.core.resources
 +
</tt>
 +
 
 +
To update your repository bringing in recent upstream changes , run the git cvsimport command again. You might want to pass the '''-i''' switch to [http://www.kernel.org/pub/software/scm/git/docs/git-cvsimport.html cvsimport].  This prevents git from automatically [http://www.kernel.org/pub/software/scm/git/docs/git-merge.html merging] ([http://www.kernel.org/pub/software/scm/git/docs/git-pull.html pulling]) changes from the remote's ''master'' into the branch you've currently checked out.  If your working tree isn't clean, has diverged, or you've checked out a different branch such automatic merge may fail.
 +
 
 +
You can see changes made in a remote with git '''log''' ''<remote_name>/<branch_name>'', and compare diffs with git [http://www.kernel.org/pub/software/scm/git/docs/git-diff.html diff]. You can [http://www.kernel.org/pub/software/scm/git/docs/git-merge.html merge] changes in, or if you haven't shared your branch with anyone else, [http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html rebase] your branch.
 +
 
 +
''Examples'': Some scripts which track Eclipse/e4 core.resources and CDT are in a [http://github.com github] repository take a look at the
 +
[http://github.com/jamesblackburn/misc/tree/master/scripts/eclipse-sync eclipse-sync] directory and the [http://github.com/jamesblackburn/misc/tree/master/scripts/eclipse-sync/sync.sh sync.sh] script.
 +
This cvsimports the projects from the Eclipse repository and pushes selected branches (HEAD and 3_4) to github.
 +
 
 +
= Working with git =
 +
 
 +
== Creating a topic branch ==
 +
 
 +
<tt> git [http://www.kernel.org/pub/software/scm/git/docs/git-checkout.html checkout] -b ''branch-name'' ''original'' </tt>
 +
 
 +
This creates a new branch ''branch-name'' based on ''original'' and switches to it. NB ''branch-name'' can contain Unix style slashes. So you might have a number of feature branches ''bug/nnnn''.
 +
 
 +
== Committing ==
 +
 
 +
<tt> git [http://www.kernel.org/pub/software/scm/git/docs/git-add.html add] ''file_paths'' </tt> <br/>
 +
<tt> git [http://www.kernel.org/pub/software/scm/git/docs/git-commit.html commit] '''-a''' </tt>
 +
 
 +
Adds some files to the index (to be tracked).
 +
 
 +
The git ''index'' is a staging post.  Files must be ''add''ed initially if you want git to track them.  You then need to git ''add'' the files you want to be part of your next ''commit''.  If you want to commit all outstanding changes the '''-a''' is provided.
 +
 
 +
== Tree Status ==
 +
Status of the tree including: <br/>
 +
<tt> git [http://www.kernel.org/pub/software/scm/git/docs/git-status.html status] </tt>
 +
 
 +
'''Changes to be committed''': changes which have been ''add''ed to the index and scheduled for the next commit.  <br/>
 +
'''dirty''' files: those which have changes since the last git ''add''. <br/>
 +
'''Untracked''' files which aren't''ignored'' <br/>
 +
 
 +
 
 +
Committed history:<br/>
 +
<tt> git [http://www.kernel.org/pub/software/scm/git/docs/git-log.html log] </tt> <br/>
 +
Diff of dirty, tracked files in the tree to the content ''add''ed to the index:<br/>
 +
<tt> git [http://www.kernel.org/pub/software/scm/git/docs/git-diff.html diff] </tt> <br/>
 +
Diff between index and HEAD of the current branch -- i.e. the changes that will be committed on git ''commit'':<br/>
 +
<tt> git [http://www.kernel.org/pub/software/scm/git/docs/git-diff.html diff] ''--cached''</tt><br/>
 +
 
 +
== Switching Branch ==
 +
 
 +
<tt> git [http://www.kernel.org/pub/software/scm/git/docs/git-checkout.html checkout] ''branch-name'' </tt>
 +
 
 +
== Generating patches for Bugzilla ==
 +
 
 +
<tt> git [http://www.kernel.org/pub/software/scm/git/docs/git-diff.html diff] --no-prefix origin/cvs/HEAD  > my_bugNNN.patch</tt>
 +
 
 +
This creates a patch my_bugNNN.patch against the ''cvs/HEAD'' branch in the origin [http://www.kernel.org/pub/software/scm/git/docs/git-remote.html remote] to the HEAD of your current branch.  This ''--no-prefix'' switch is needed to allow the patch to be applied by the Eclipse Apply-Patch wizard.
 +
 
 +
== Sharing changes with other git'ers ==
 +
 
 +
Add a 'remote': <br/>
 +
<tt> git [http://www.kernel.org/pub/software/scm/git/docs/git-remote.html remote] add ''remote_name''  ''url'' </tt><br/>
 +
Fetch changes from it: <br />
 +
<tt> git [http://www.kernel.org/pub/software/scm/git/docs/git-fetch.html fetch] ''remote_name'' </tt><br />
 +
Create a new branch from remote branch:  <br/>
 +
<tt> git [http://www.kernel.org/pub/software/scm/git/docs/git-checkout.html checkout] -b ''branch-name'' ''remote_name/remote_branch'' </tt> <br/>
 +
... Do some stuff ... <br/>
 +
Push changes <br/>
 +
<tt>git [http://www.kernel.org/pub/software/scm/git/docs/git-push.html push] ''remote_name'' ''my_branch:remote_branch''</tt> <br/>
 +
... Do some stuff ... <br/>
 +
Pull changes (git ''fetch'' followed by git ''merge''):  <br/>
 +
<tt>git [http://www.kernel.org/pub/software/scm/git/docs/git-pull.html pull] ''remote_name/branch''</tt> <br/>
 +
 
 +
= Git magic =
 +
 
 +
== Un-forking e4 ==
 +
 
 +
The e4 repository was forked from 3.x by copying the history in the eclipse.org repository.  Both repositories therefore share the same initial history, and are ideal for placing in two different branches in git.
 +
 
 +
To do this, we trick cvs-import into importing both repos into different ''remotes'' in the same git repository.
 +
 
 +
e.g. org.eclipse.core.resources:
 +
 
 +
1) import org.eclipse.core.resources: <br/>
 +
<tt>git cvsimport -i -v -C eclipse-core-resources -d :pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse -r cvs org.eclipse.core.resources</tt>
 +
 
 +
2) ''start'' to import e4 core resources: <br/>
 +
<tt>git cvsimport -i -v -C '''e4-core-resources''' -d :pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse -r cvs_e4 e4/org.eclipse.e4.resources/bundles/org.eclipse.core.resources</tt><br/>
 +
 
 +
When you see the first commit happen during the e4 cvs-import, cancel the process.
 +
 
 +
3) <tt>cat e4-core-resources/.git/refs/remotes/cvs_e4/master</tt>
 +
 
 +
This will show the hash that the cvs_e4 master currently imported.  git is essentially a UI on a hashed object store (DAG).  The branches, tags, etc. are simply pointers to tree state hashes.  Do read [http://eagain.net/articles/git-for-computer-scientists/ git for computer scientists] -- it's neat and simple!
 +
 
 +
4) <tt>cd eclipse-core-resources </tt><br/>
 +
5) <tt>git log</tt>
 +
 
 +
Search for the hash id from e4. It ''should'' be there (after all both repos share the same common ancestry.
 +
 
 +
6) In git log note the hash of the ''first'' commit: '''first_commit_hash'''.
 +
 
 +
<tt> mkdir .git/refs/remotes/cvs_e4 </tt> <br/>
 +
<tt> echo '''first_commit_hash''' > .git/refs/remotes/cvs_e4/master </tt>
 +
 
 +
7) <tt>git cvsimport -i -v -C '''eclipse-core-resources''' -d :pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse -r cvs_e4 e4/org.eclipse.e4.resources/bundles/org.eclipse.core.resources</tt><br/>
 +
 
 +
When the history (tree hash) diverge, so will the e4 and 3.x branches.
 +
 
 +
 
 +
From then on it's as simple as: <br/>
 +
<tt>git cvsimport -i -v -C eclipse-core-resources -d :pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse -r cvs org.eclipse.core.resources</tt><br/>
 +
<tt>git cvsimport -i -v -C eclipse-core-resources -d :pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse -r cvs_e4 e4/org.eclipse.e4.resources/bundles/org.eclipse.core.resources</tt>
 +
 
 +
See the import [http://github.com/jamesblackburn/misc/tree/master scripts] that track various eclipse repos.
 +
 
 +
== Merging HEAD changes to e4 ==
 +
 
 +
With Eclipse HEAD and e4 in the same repository, git can be used to do most the heavy merg lifting.
 +
 
 +
Taking org.eclipse.ui.ide as an example:
 +
 
 +
<tt>mkdir  3.5m6-merge/ <br/>
 +
''Open Eclipse using with workspace 3.5m6-merge as workspace...''<br />
 +
git clone git://github.com/jamesblackburn/eclipse-ui-ide.git org.eclipse.ui.ide <br />
 +
cd org.eclipse.ui.ide <br/>
 +
''Eclipse: Import Project org.eclipse.ui.ide into workspace...''<br/>
 +
git checkout -b merge_e4 origin/cvs_e4/HEAD<br/>
 +
git merge origin/cvs/HEAD <br/> <br/>
 +
'' ... In Eclipse: Refresh and resolve conflicts by...'' <br/>
 +
git diff <filename>    <== will show the hunks requiring merge <br/>
 +
git log --merge -p <filename>  <== will show the commits which touch file (commit id / comment + diff) <br/>
 +
git add <merged_file> <br/>
 +
git status  <== lists no more merge failures<br/>
 +
git commit <br/>
 +
 
 +
Produce diff for upstream bugzill:
 +
git diff --no-prefix origin/cvs_e4/HEAD > merge_diff.patch
 +
</tt>
 +
 
 +
NB having performed a resource changing operation externally, remember to '''Refresh''' in Eclipse => ''Right click on Project > Refresh''. Check for build errors.
 +
 
 +
= Reference =
 +
[http://www.kernel.org/pub/software/scm/git/docs/everyday.html Git in 20 Commands]
 +
 
 +
[http://ktown.kde.org/~zrusin/git/git-cheat-sheet-large.png Git Cheat-Sheet]
 +
 
 +
[http://eagain.net/articles/git-for-computer-scientists/ Git for Computer Scientists]
 +
 
 +
[http://git-scm.com/documentation Git Documentation home]
 +
 
 +
[http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html Git for everyone (tutorial)]
 +
 
 +
[http://www.vogella.com/articles/Git/article.html Git tutorial from Lars Vogel]
 +
 
 +
== Help for other VCS refugees ==
 +
 
 +
[http://git.or.cz/course/svn.html Git for SVN users]
 +
 
 +
[http://www.chem.helsinki.fi/~jonas/git_guides/HTML/CVS2git/ CVS to Git]
  
 
= Using the EGit integration=
 
= Using the EGit integration=
  
== Contributing to EGit ==
+
== Contributing to EGit or JGit ==
 +
 
 +
If you want to get involved with EGit or JGit, please see the EGit and JGit projects.
 +
 
 +
Loading it into Eclipse is as simple
 +
as importing the existing projects from the checked-out repository.  Please see
 +
'''SUBMITTING_PATCHES''' in the top level directory for information on how to send
 +
contributions in.
  
 
= Known git repositories for Eclipse projects =
 
= Known git repositories for Eclipse projects =
 +
* Eclipse.org Hosted Git Repositories: http://git.eclipse.org/c/
 +
* Read-only git of all Eclipse CVS: See http://dev.eclipse.org/git/ (Projects that have migrated to Git will not be current here)
 
* [[Swordfish Documentation: GIT Repository]]
 
* [[Swordfish Documentation: GIT Repository]]
* [[Linux Distributions Packaging Status]]
 
 
* [[SWTBot]]:  http://github.com/ketan/swtbot/
 
* [[SWTBot]]:  http://github.com/ketan/swtbot/
 +
* [http://wiki.eclipse.org/STP/BPMN_Component BPMN Modeler] http://github.com/atoulme/bpmn-modeler/
 +
 +
== Misc ==
 +
 +
* [http://github.com/jamesblackburn/misc/tree/master/scripts/eclipse-sync Simple Eclipse sync scripts]
 +
 +
= Meetings and Resources =
 +
* [https://www.eclipsecon.org/submissions/2009/view_talk.php?id=776 GIT BoF at EclipseCon 2009]
 +
* [http://www.eclipsecon.org/2009/sessions?id=823 VCS panel at EclipseCon 2009]
  
 
[[Category:Architecture Council]]
 
[[Category:Architecture Council]]

Revision as of 04:18, 13 May 2012

Background

Motivation

DVCS make cheap branches a first class concept. When everyone has their own branch / fork it's up to the VCS to make local changeset management easy and the merge process as painless as possible.

This guide illustrates how you might use git to increase productivity when developing Eclipse. Even committers with access to the centralized repository will benefit. After all a committer can't (shouldn't!) commit work-in-progress to a repo relied on by millions of users. git makes the process of tracking and merging upstream changes painless, and allows quick and easy patch regeneration for bugzilla review.

The guide does not aim to give an exhaustive overview of the commands and how they work. There is large body of existing documentation under #Reference.

Related

Bugs

  • bug 257706 Host a git repository on Eclipse Foundation servers, support git as the repository of Eclipse projects
    • bug 257706#c63 Mike M. on potential problems with git at the Foundation
  • bug 249745 Eclipse Repository Best Practices

Setting up git

Easy-setup

Has someone already imported the repository for you? If so clone or fork theirs! Creating the repository from scratch is straightforward, but beware the initial checkout is very time consuming. (It's also not very friendly to the Eclipse CVS servers; git has to reconstruct the individual commits and checkout each changeset individually...) (See #Known_git_repositories_for_Eclipse_projects).

Cloning a repository is as easy as:

git clone <repo_url> my_checkout_dir_name

e.g. git clone git://github.com/jamesblackburn/eclipse-core-resources-tests.git org.eclipse.core.tests.resources

Importing a repo

The process of creating a repository is the same whether you're an existing committer or not.

Tracking only your own changes

If you're only interested in your own changes and/or don't care about importing existing commit history from a legacy repository, you can just tell git to start tracking changes in a specific directory tree. Turn any directory into a versioned repository with the sequence:

git init
git add .
git commit

Importing from CVS

git cvsimport -v -C eclipse-core-resources -d :pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse -r cvs org.eclipse.core.resources

This command creates a new git repository importing all the history, in this case, from the org.eclipse.core.resources repository.

This commands says: import the org.eclipse.core.resources module into a git repository in the directory (-C) eclipse-core-resources. The -r switch says to store the loaded repository data under the cvs remote. A remote is like a git branch except you never checkout a remote directly. You'll create your own branches based on remote versions. The remote branches must be kept clean for when you next fetch updates from the remote.

With that one command you now have a fully-fledged repository waiting for you. Take a look:

cd eclipse-core-resources
git branch -a
git log

git branch -a will show all the branches -- you'll see this contains all the upstream branches, potentially a lot! You'll see that you're currently sitting in master which cvsimport has created for you tracking the cvs/master remote branch. git log shows you the full imported commit history on this branch.

Staying fresh

git cvsimport -i -v -C eclipse-core-resources -d :pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse -r cvs org.eclipse.core.resources

To update your repository bringing in recent upstream changes , run the git cvsimport command again. You might want to pass the -i switch to cvsimport. This prevents git from automatically merging (pulling) changes from the remote's master into the branch you've currently checked out. If your working tree isn't clean, has diverged, or you've checked out a different branch such automatic merge may fail.

You can see changes made in a remote with git log <remote_name>/<branch_name>, and compare diffs with git diff. You can merge changes in, or if you haven't shared your branch with anyone else, rebase your branch.

Examples: Some scripts which track Eclipse/e4 core.resources and CDT are in a github repository take a look at the eclipse-sync directory and the sync.sh script. This cvsimports the projects from the Eclipse repository and pushes selected branches (HEAD and 3_4) to github.

Working with git

Creating a topic branch

git checkout -b branch-name original

This creates a new branch branch-name based on original and switches to it. NB branch-name can contain Unix style slashes. So you might have a number of feature branches bug/nnnn.

Committing

git add file_paths
git commit -a

Adds some files to the index (to be tracked).

The git index is a staging post. Files must be added initially if you want git to track them. You then need to git add the files you want to be part of your next commit. If you want to commit all outstanding changes the -a is provided.

Tree Status

Status of the tree including:
git status

Changes to be committed: changes which have been added to the index and scheduled for the next commit.
dirty files: those which have changes since the last git add.
Untracked files which aren'tignored


Committed history:
git log
Diff of dirty, tracked files in the tree to the content added to the index:
git diff
Diff between index and HEAD of the current branch -- i.e. the changes that will be committed on git commit:
git diff --cached

Switching Branch

git checkout branch-name

Generating patches for Bugzilla

git diff --no-prefix origin/cvs/HEAD > my_bugNNN.patch

This creates a patch my_bugNNN.patch against the cvs/HEAD branch in the origin remote to the HEAD of your current branch. This --no-prefix switch is needed to allow the patch to be applied by the Eclipse Apply-Patch wizard.

Sharing changes with other git'ers

Add a 'remote':
git remote add remote_name url
Fetch changes from it:
git fetch remote_name
Create a new branch from remote branch:
git checkout -b branch-name remote_name/remote_branch
... Do some stuff ...
Push changes
git push remote_name my_branch:remote_branch
... Do some stuff ...
Pull changes (git fetch followed by git merge):
git pull remote_name/branch

Git magic

Un-forking e4

The e4 repository was forked from 3.x by copying the history in the eclipse.org repository. Both repositories therefore share the same initial history, and are ideal for placing in two different branches in git.

To do this, we trick cvs-import into importing both repos into different remotes in the same git repository.

e.g. org.eclipse.core.resources:

1) import org.eclipse.core.resources:
git cvsimport -i -v -C eclipse-core-resources -d :pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse -r cvs org.eclipse.core.resources

2) start to import e4 core resources:
git cvsimport -i -v -C e4-core-resources -d :pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse -r cvs_e4 e4/org.eclipse.e4.resources/bundles/org.eclipse.core.resources

When you see the first commit happen during the e4 cvs-import, cancel the process.

3) cat e4-core-resources/.git/refs/remotes/cvs_e4/master

This will show the hash that the cvs_e4 master currently imported. git is essentially a UI on a hashed object store (DAG). The branches, tags, etc. are simply pointers to tree state hashes. Do read git for computer scientists -- it's neat and simple!

4) cd eclipse-core-resources
5) git log

Search for the hash id from e4. It should be there (after all both repos share the same common ancestry.

6) In git log note the hash of the first commit: first_commit_hash.

mkdir .git/refs/remotes/cvs_e4
echo first_commit_hash > .git/refs/remotes/cvs_e4/master

7) git cvsimport -i -v -C eclipse-core-resources -d :pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse -r cvs_e4 e4/org.eclipse.e4.resources/bundles/org.eclipse.core.resources

When the history (tree hash) diverge, so will the e4 and 3.x branches.


From then on it's as simple as:
git cvsimport -i -v -C eclipse-core-resources -d :pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse -r cvs org.eclipse.core.resources
git cvsimport -i -v -C eclipse-core-resources -d :pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse -r cvs_e4 e4/org.eclipse.e4.resources/bundles/org.eclipse.core.resources

See the import scripts that track various eclipse repos.

Merging HEAD changes to e4

With Eclipse HEAD and e4 in the same repository, git can be used to do most the heavy merg lifting.

Taking org.eclipse.ui.ide as an example:

mkdir 3.5m6-merge/
Open Eclipse using with workspace 3.5m6-merge as workspace...
git clone git://github.com/jamesblackburn/eclipse-ui-ide.git org.eclipse.ui.ide
cd org.eclipse.ui.ide
Eclipse: Import Project org.eclipse.ui.ide into workspace...
git checkout -b merge_e4 origin/cvs_e4/HEAD
git merge origin/cvs/HEAD

... In Eclipse: Refresh and resolve conflicts by...
git diff <filename> <== will show the hunks requiring merge
git log --merge -p <filename> <== will show the commits which touch file (commit id / comment + diff)
git add <merged_file>
git status <== lists no more merge failures
git commit

Produce diff for upstream bugzill: git diff --no-prefix origin/cvs_e4/HEAD > merge_diff.patch

NB having performed a resource changing operation externally, remember to Refresh in Eclipse => Right click on Project > Refresh. Check for build errors.

Reference

Git in 20 Commands

Git Cheat-Sheet

Git for Computer Scientists

Git Documentation home

Git for everyone (tutorial)

Git tutorial from Lars Vogel

Help for other VCS refugees

Git for SVN users

CVS to Git

Using the EGit integration

Contributing to EGit or JGit

If you want to get involved with EGit or JGit, please see the EGit and JGit projects.

Loading it into Eclipse is as simple as importing the existing projects from the checked-out repository. Please see SUBMITTING_PATCHES in the top level directory for information on how to send contributions in.

Known git repositories for Eclipse projects

Misc

Meetings and Resources