Mercurial vs git
Andy.Henshaw at gtri.gatech.edu
Andy.Henshaw at gtri.gatech.edu
Fri Jan 5 18:13:34 UTC 2007
List members,
I summarized many of the responses to my original note and sent them
along to the git champion. Here is a portion of my note (my words have
a > prepended), along with his responses:
--------- begin ---------
>Complexity
>Hg is widely considered to be much easier to use. Apparently,
Viz complexity, the cogito suite (that wraps around git) completely
hides the index, hides a lot of other things, and provides as simple an
interface as hg. Also, with git, just do git commit -a (assuming
.gitignore is correctly set up) and forget the index exists. There is a
lot of power to having the index, but you aren't forced to deal with it
if you don't care. Sacrificing needed functionality to gain simplicity
is a bad tradeoff, and that is the essence of the git / hg differences
for me.
>git branch -d : clone -r
hg clone -r is much less capable, requires a lot of fiddling, etc. to do
the equivalent of git -D tmp/stupidbranch while keeping the 50 other
branches and all history.
>git merge -squashed : hg revert -r; hg ci
I am not reverting a single checkin, not necessarily even a simple
sequence. Could be commits 1 4 8 12 on a branch with 23 other things.
Also, git rebase is essential in the process. Keep in mind, we do not
actually do linear development, things do not happen in a particular
order and we need the tool to let us merge things in the order we need,
not the order convenient to the tool.
>git diff -diff-filter=MRC -name-status : No direct equivalent.
>gitk : hg view
I didn't get that (am using hg 0.93, maybe this is a more recent
innovation?). Google search tells me this is a direct port of gitk, if
so I concede it is just my setup problem.
>git-cvsserver : no direct equivalent
>hg addremove --similarity ; hg commit
>(or hg commit --addremove if you don't care about renames)
>From an Hg user: "git doesn't record renames/copies anywhere. So it
_always_ has to guess. Mercurial records this information, and can
rebuild the ancestry tree with 100% confidence (assuming you use the mv
and cp commands hg provides)." In addition, git does have 'git-add' and
'git-rm' commands, so the concept is apparently useful to them also.
>From a git user: I haven't found full history of a renamed file to be
that useful, but git's "guesses" have all been right in my tests.
Especially if you a) move the file and commit it, then change it. In
this case, the contents haven't changed, therefore the blob name is the
same, and no confusion is possible. What I do find extremely useful is
git's ability to figure out what has happened, and that it is change-set
rather than file history based. It is a different mind set (keep the
states, allow very flexible queries as to the difference between any two
states as you are investigating problems, etc).
git-add is a wrapper around git-update-index and used to add things to
the commit set. git-rm is used to delete from the commit set. This
doesn't have an equivalent in hg. As I stated above, git commit -a adds
what is new, removes what doesn't exist any more, and includes what is
changed.
More information about the Mercurial
mailing list