Sunday, July 11, 2010

I do not like git

Recently I had to use git for the first time. I'm used to using Mercurial instead. For those of you not familiar with these programs, they're both distributed source control managers (SCM's), which are used for maintaining a history of changes you've made to an application or other project.

In many ways, git is extremely hostile. If you're considering git or Mercurial, use the latter.

Examples:
  1. To commit all changes in Mercurial, do hg commit. In git, git commit only commits added or moved files; to commit all changes, you have to do git commit . (why?).
  2. To see all changes in Mercurial, do hg diff. Added or moved files are shown appropriately (using diffs to/from null, or using a move foo to bar statement + a cross-file diff if you use hg diff --git -- ironically, since git can't do this!). In git, git diff does NOT show added or moved files that you haven't checked in, and there seems to be no option to make it show them. (Hence, the only way to figure out whether you have added or moved files is to run git commit to see what it says will be done, and then exit from the editor without changing anything, to abort the commit.)
  3. To revert a file back to the latest repository version in Mercurial, do e.g. hg revert foo.c. To revert all files, do hg revert --all. In git, to revert a file, you have to do git checkout HEAD -- foo.c (super obvious, no?), but to revert all files, you use a totally different incantation: git reset --hard. Note that neither of these git incantations uses git revert, which does something else entirely (check out an earlier version of the repository and then commit it).
  4. Commits in Mercurial are given sequential numbers starting from 1, to be used locally for convenience, as well as a long (32-hex-digit) globally unique commit identifier. git, naturally, is trying to be hostile, so it doesn't have anything like Mercurial's sequential numbers. The only way to identify a commit is using some fairly long subset of the commit ID (long enough to be unique, but I assume you can only find that out by trying it and seeing if git complains), or using something like HEAD~3 i.e. 3 commits before the last one. The latter works ok if you're referring to very recent commits, but for older commits your only option is the long hexadecimal commit ID's.

No comments:

Post a Comment