Thoughts on Mercurial and Git

[Theodore Tso]

On Tue, Mar 27, 2007 at 08:41:22AM -0700, Brendan Cully wrote:
> 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/

Nice.

> 
> > I also gather that someone is working on the branching problem.
> 
> Yes. It still needs a fair amount of cleanup, but proof-of-concept
> code lives here:
> 
> http://hg.kublai.com/mercurial/patches/localbranch/

The one thing that I do wonder about both of these approach is that
they handles the "overlay" and the "local branch" as a special case.
This works, but in the long run I can forsee some potential problems.

For example, what if you have a changeset which is on the local
branch, which and then some or all of the branch gets pushed to the
mainline, and then gets pulled back down into primary, aster revlog.
Is there any way to make the changeset on the local branch go away
without destroying and recreating the entire branch?  (This is another
case of the only-way-you-can-remove-revisions-is-by-truncating design
tradeoff in hg.)

A similar issue exists in the overlay changes.  Right now, I have a
single git repository which mirrors Linus's kernel tree, and I never
check anything into it. I call that my "base".  All of my other git
trees for the kernel use "base" as git's alternate objects directory,
so only objects that aren't in Linus's tree needs to be stored in my
local git repositories.  So far so good; this could map into the hg
overlay model fairly easily.  But sometimes changes which are in my
local repository will get pushed or pulled into mainline, which means
they will appear in "base".  At that point, is there any way for the
changeset which is in the local revlog to get garbage collected?  I
don't think so.

On another point, I'm curious.  Does your overlay patch allow for a
user to create an overlay, and then make changes in the overlay, and
then later, after new changes are pulled from mainline into "base",
and then when the overlay pulls from the base, to use the new changes
from the base?  Or is that once you have made changes in the overlay,
that all changes must be appended to the overlay, even if that means
you are copying them from the original base repository of the overlay?
The overlay patch could have been implemented either way, and I'm not
sure how it was done.

Hmm, thinking this some more, I guess this would be my one true
"complaint" about Hg.  Git just seems architecturally cleaner, in
terms of being able to handle overlay repositories and local branches
in a much cleaner way, without needing special cases.  That doesn't
mean that Hg shouldn't try to do it, but that it will probably be more
difficult for Hg to add these features than it was for git.  But
that's a technological aesthetics argument, not a
feature/functionality or performance argument.

Regards,

						- Ted