Re: preferring mercurial

[Stephen J. Turnbull]

Jordi Gutiérrez Hermoso writes:

 > In hg the problem is much easier to solve without server-side access:
 > just push another commit closing-branch commit on the extra head that
 > you don't want to keep working on.

You don't seem to understand what the problem is.  Consider an hg repo
with 100 bookmarks, all of which suddenly point to completely
different places -- or worse, places that at a glance look like where
you should be but in fact are different.  Now figure out how to
re-associate the 100 bookmarks with the correct dangling heads.  Why
is this easier in hg than it would be in git?

 > > Unfortunately, no.  The actual behavior of hg is indeed immediately
 > > destructive in some cases, unlike git.
 > 
 > git has immediately destructive operations too, for example the
 > "git reset HEAD --hard" that everyone blindly memorises (who really
 > can keep all of the kinds of resets straight?)

I haven't had any trouble. <shrug/>

 > will destroy all unstaged changes.

Indeed.  But unstaged changes aren't history yet, by definition.  (And
in git staged changes are: there will be objects to match in the object
database.)

Anyway, my point has never been that git doesn't have issues, even
design bugs such as the lockless gc.  The point is that as far as DAG
manipulations go, it's easy to reason about what git will do and where
commits will be if they get lost.  Even about GC -- if multiple GC
processes are running, you're going to get corruption. :-P

But hg ... for example, don't you think it's kinda gross that hg
(including Evolve) has 3 different backup mechanisms that you've
mentioned so far (.orig, strip backup, hidden obsolete commit)?  And
there may be variations on some of them (does hg have a "git-stash"
equivalent?  which format does it use? are strip backups == bundles ==
mq patches?  if so, why the proliferation of names?  if not, how do
they differ?)  Not to forget that Mercurial has 2.5 kinds of branch
structure: bookmarks, named branches, and the special named branch
"default".)

In the case of git, you just branch.  (OK historically there was
quilt, but quilt really prexisted even bitkeeper.)  And there's only
one kind of branch structure: the transitive closure of the parent
relation for a commit.  A stash is a specialized branch.  The reflog
is a collection of specialized branches with algorithmically generated
names.  A tag is more or less a closed branch.  Tracking branches help
you keep your upstream and downstream straight.  Doing something
dangerous?  Tag or branch and work on that -- and you needn't even
fear gc.

                           ****************

I know there are a lot of people who want to blindly memorize recipes
and never think about their tools.  Mercurial is great for them.  But
every time I say "what about ..." you respond, "oh, there's a hack for
that" (and in a VCS, keeping diffs as a backup is definitely a hack).
Proliferation of special hacks makes it hard to think about such tools.

But I think that Emacs users by and large *do* think about their
tools.  Sure, Eli dislikes git and has refused to work on Bazaar.  But
that's more or less an accident: I know from other MLs that he works
on DJGPP and gdb and AFAIK neither is his job -- he could let other
people do that, too.  But he doesn't, he contributes.

Thing is, there are a lot of folks in Emacs who *do* care to think
about VCS.  Karl Fogel wrote one, for heaven's sake.  ESR clearly
thinks about VCS a lot (to the extent that he still considers himself
maintainer of vc.el).  Andreas obviously knows git inside out.  DAK
has threatened to contribute patches to git.  And that's just off the
top of my head.  You may not see a difference between the design of
git and hg, but I do, and I think Emacs developers are more likely to
make Emacs-relevant contributions to git's ecosystem than to hg's.