MenTaLguY wrote:
On Sat, 2007-12-08 at 12:47 -0600, Aaron Spike wrote:
Mental, what parts of git do you feel are particularly user unfriendly that are less so in mercurial?
I think git forces you to think a little bit more about the revision tree when you work (which might not actually be a bad thing, as far as it goes...), basic status information is hard to come by with a single command (I use cg-status from cogito instead), and a few things are still needlessly inconvenient (e.g. pushing to a remote branch doesn't update the locally cached copy).
The big thing, though, is Win32 support. Mercurial just works on Win32, and there is even a TortoiseHg for Windows shell integration. I think the best you can do with git right now is a version compiled with cygwin, although there is a mingw port being worked on as well.
Aside from the excellent design of the git repository format, git's advantages lie mainly in its superior handling of branches and in its usefulness for quickly analyzing large revision histories -- I was recently able to quietly resolve a copyright dispute by analyzing our git history in minute or two, which, even if the tools were available, would have taken inhumanly long if I'd had only subversion to work from.
Actually, that gets to one of my pet peeves about Mercurial, though -- it does actually come with a number of nice analysis tools which emulate many of the best features in git (e.g. "bisect", which does a great job of automating searches for the revision that introduced a bug, especially when the history is complex and non-linear). They just aren't enabled by default: as extensions, you need to enable each one individually in a Mercurial configuration file on a per-user basis. Which is stupid.
Now, one nice thing about Mercurial and git is that, even though they have different repository formats, git and mercurial share a basic change model, so if we went with Mercurial, two-way interoperation between git and mercurial could still be nicer than with subversion. The story is generally not quite as nice for most other revision systems (though most of the DSCMs are reasonably compatible).
-mental
For us, the big reason for a distributed system is the ability to work off-line (ie on a plane, train, in a cafe, during a boring meeting, etc) and then post up a day or two later. Or to work on something in a more sandbox situation for a few days or weeks and then upload and have it merged in. Meanwhile it makes frequent committing easy which is a good thing. I have tried both hg and bzr and if both were very easy for me to learn, not much effort will be required for most of you. We're now using hg. Of the two, I had read that bzr was really slow in bigger uploads/merges but maybe the Ubuntu guys can speak to that better.