On Tue, Jan 30, 2007 at 11:55:48AM -0500, Shawn O. Pearce wrote: > I think hg modifies files as it goes, which could cause some issues > when a writer is aborted. I'm sure they have thought about the > problem and tried to make it safe, but there isn't anything safer > than just leaving the damn thing alone. :) To be fair hg modifies files using O_APPEND only. That isn't quite as safe as "only creating new files", but it is relatively safe. One other interesting point which came as a surprise to me is the size of the repositories. It used to be that git was much more inefficient at storing files that Mercurial. However, what pack files, and deltas, I'm pleased to say a mercurial repository with all of e2fsprogs' history is 20 megs, while a git repository with the same history is 11 megs. (BTW, I've been doing some hacking of Stelian Pop's hg2git.py in my spare time. Most of the changes are e2fsprogs specific, but if anyone else is hacking on it, I'd love to compare notes. I have some vague thoughts about making hg2git to be bidirectional, but I probably won't have time to implement it.) > Yes. By a huge margin. Git's *fast*. Ignore anything from a year > or two ago. I'd go even further. You probably want to use the latest git 1.5.0 rc release, or final, since it has been a lot uf usability and documentation improvements over previous git releases. > > 4. What is git's index good for? I find that I like the idea of it, > > but I'm not sure I could justify it's presence to someone else, as > > opposed to having it hidden in the way that hg's dircache (?) is. Can > > anyone think of a good scenario where it's a pretty obvious benefit? In git 1.5.0 it's a lot easier for users to not have to worry about the index if they don't want to. It's not quite so much in the user's face, although there is still improvement to be had, especially in the git documentation. There is a git user's manual being prepared (that I think will be in 1.5.0, hopefully) that is much better than "man git". > This really helps during a merge. Only the stuff which Git could > not merge for you is seen as different between the index and the > working directory; all of the stuff that Git merged for you is > already staged in the index. So you can focus on the conflicts, > and stage their resolutions into the index as you go. This makes > it easier to work through larger merges where more than 1 or 2 > files contains conflicts. The flip side of this is that mercurial as much better integration with graphical merge tools, which git doesn't have by default (yet). > > 8. It feels like hg is not really comfortable with parallel > > development over time on different heads within a single repo. > > Rather, it seems that multiple repos are supposed to be used for this. > > Does this lead to any problems? For example, is it harder or > > different to merge two heads if they're in different repo than if > > they're in the same repo? hg has only recently added support for development on different heads within the same repo. So it's just more immature there. Presumably over time it will get better. Most poeple who use use hg don't use a lot of different branches, for things like topic branches, for example. If you prefer to use that style of interaction, git is going to be a much better choice for you. Regards, - Ted - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html