Friday, July 29, 2011

Git Migration and ignore files

As I mentioned in Git Migration I've been involved in the Platform UI CVS to Git migration using the cvs2git tool.

After your first successful conversion of a test repo, you fire it up in eclipse and check it out. That's when you see ... a lot of untracked changes! Oh yeah, all our .cvsignore files are useless :-)

Obviously we wanted a .gitignore at the root of our repo, from the beginning of time ... just like the catchphrase "there's an app for that", git will allow you to re-write your history so that it looks like the .gitignore was in every branch and tag since day one (How do I make a git commit in the past?).  Obviously since this is a re-write, you need to do this as the last step before you publish your repo.

  1. create suitable file contents
  2. add it to your repo
  3. re-write all of the index trees in each commit to add the file
  4. reset your repo


Here's the example as fed into bash:

bash$ cat - >../gitignore <<EOF
bin/
*~
*.rej
*.bak
*.patch
javacore.*
heapdump.*
core.*
Snap.*
target/

EOF
bash$ new_file=$(git hash-object -w ../gitignore)
bash$ git filter-branch \
--index-filter \
'git update-index --add --cacheinfo 100644 '"$new_file"' .gitignore' \
--tag-name-filter cat \
-- --all
bash$ git reset --hard

Now I have a .gitignore at the root of my repo, and my status and EGit views are not cluttered with spurious untracked files. Rinse and repeat for more specialized .gitignores in various project directories that need them.

Wednesday, July 20, 2011

Git Migration

A large part of the Open Source world seems hot on git these days (and DVCSs in general). I can kinda see why. For tracking changes, the notion of a commit definitely makes more sense than updating the versions on files that CVS has to offer. The ease of creating git repos plays well with one of my own beliefs, which is "Even for one's own little projects, if it's not in a VCS it may as well be written on the back of a napkin". Social coding sites like GitHub offer an ease of contributing to projects that contributors love, and git makes it easier to keep contributions (commits) from going stale than when dealing with patches in email or bug tacking systems. Git itself has useful tools for visualizing your repo (like gitk), tracking down when a bad behaviour was introduced (git blame), and a dozen others besides.

And for those that miss their C roots, you can pretend your git hashes are pointers: 5eec2b04a70f704a7cdc1b77db59bb90ec03dd68 :-)

With the Eclipse Foundation also interested in supporting git as its main VCS, the Eclipse Project decided to move to git at the beginning of the Juno Release cycle. I've been involved with the Platform UI component migration.

I'll write a second post soon with more details about the problems we encountered and some of the steps we took, but after a grueling 2 weeks the conversion of this component is done. Woo Woo!

  • git://git.eclipse.org/gitroot/platform/eclipse.platform.runtime.git
  • git://git.eclipse.org/gitroot/platform/eclipse.platform.ui.git
  • git://git.eclipse.org/gitroot/e4/org.eclipse.e4.tools.git