Thoughts on Mercurial and Git

[Alexis S. L. Carvalho]

Thus spake Brendan Cully:
> On Tuesday, 27 March 2007 at 09:08, John Goerzen wrote:
> > Hi everyone,
> > 
> > There's been some interesting discussion lately about Git and Mercurial.
> > Ted T'so, a Linux kernel hacker and maintainer of ext2/ext3, uses
> > Mercurial for e2fsprogs, but comments about thinking of switching it to
> > git here:
> > 
> > http://tytso.livejournal.com/29467.html
> > 
> > Ted is a very sensible person that I respect quite a bit, and I think
> > he's got some valid points.
> > 
> > He also commented on my post about why I'm still using Mercurial here:
> > 
> > http://changelog.complete.org/posts/596-Some-more-git,-mercurial,-and-darcs.html
> > 
> > again with some valid points.
> > 
> > His main complaints against Mercurial seem to be:
> > 
> >  * Difficulty of extending it without using Python
> > 
> >  * Lack of git-style in-tree branches
> >    (I have to say I think hg's in-tree branches don't work for my
> >    workflow, either)
> >  
> >  * Repository size and performance
> > 
> >  * Future features
> > 
> > I'm not planning to switch to git anytime soon, but I'm wondering what
> > people in this community think about all that.  Personally I think that
> > the repo size and performance are "nice to haves" (hg is plenty fast for
> > me and nearly as small at git).
> > 
> > But having the history of each file stored in individual history files
> > makes hardlinking the history pretty much useless in some cases.  (Apply
> > one change that impacts 50% of the files and 50% of your hardlinks have
> > to go away, even if you're just updating a copyright date)
> 
> My overlay patch series handles this case nicely. Only the actual
> changes are stored, and the original revlogs are consulted for
> everything else.
> 
> http://hg.kublai.com/mercurial/patches/overlay/

One thing that I'd like to try on top of overlay (but don't hold your
breath waiting for it) is to change things so that an initial clone,
instead of creating one revlog for every tracked file, creates a single
superrevlog that is essentially the concatenation of the individual
revlogs (and a metaindex file to be able to find stuff in there).  This
superrevlog would be a read-only file and new revisions would create
overlayed revlogs on demand.

This should minimize the space lost due to tracking many small files,
which accounts for the largest part of the difference in size between a
hg and a git repo.  Even so the (packed) git repo would probably remain
a bit smaller (especially if you hand-tune some options).

Another possibility would be to just use the same repository with
multiple working directories.  This should mostly work right now by just
symlinking .hg/store .  The idea of a clone --shared that would set this
up in a portable, symlink-less way has come up a few times.

Working in the resulting repos would probably bring some usability
problems (hg tip isn't very interesting anymore (since you may have
updated the repo from another wd), hg log will by default show the
history of the whole repo, which is probably not what you want, "what
should 'hg up' do" is an interesting question (which becomes much easier
to answer with named branches)).

Alexis