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.

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 replied 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.

+

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]].

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]].

Line 75:

Line 75:

''Examples'': Some scripts which track Eclipse/e4 core.resources and CDT are in a [http://github.com github] repository take a look at the

''Examples'': Some scripts which track Eclipse/e4 core.resources and CDT are in a [http://github.com github] repository take a look at the

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.

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.

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.

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'''.

** Something along the lines of [http://ketan.padegaonkar.name/2009/01/24/using-mercurial-with-eclipse-cvs.html Ketan's blog for Mercurial]

+

−

* Known Issues and Gotchas

+

−

** Initially pulling from CVS into a repo puts HEAVY load on the Eclipse CVS server ... better clone an existing git repo if available (Can be used as a a form of a torrent, it is possible to pull from someone else I know, and sync with eclipse servers, they're all the same repositories after all)

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.

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).

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:

Importing from CVS

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:

gitbranch -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. gitlog shows you the full imported commit history on this branch.

Staying fresh

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.

Committing

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

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

Generating patches for Bugzilla

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.

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.

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.