Re: On the subject of Git, Bazaar, and the future of Emacs development

["Stephen J. Turnbull" <stephen@xemacs.org>]

Michael Welsh Duggan writes:

 > I see these Git versus Bazaar arguments pop up every now and then on
 > this forum.  I must admit my experience with Git has been better than
 > that with Bazaar, but I have to ask, why isn't Mercurial being
 > considered?

Nobody in the community is using it to develop Emacs, would be the
reason I expect.

Mercurial is perfectly serviceable, XEmacs and Python both use it.
However, it really isn't as powerful or coherent as git, and the DAGs
it creates tend to be rather ugly unless you have a standard
project-wide workflow.  The lack of a good colocated branch story[1]
hurts in many workflows (as indeed it does in Bazaar). Nobody does
submodules well yet, but I'll bet git gets there first because git's
implementation is such a natural extension of Linus's original model.

Despite the constant criticism of git's command-line UI[2], IMO it's a
red herring for Emacs use[3].  In git's favor, git has a powerful
(though incomplete in some respects[4]) model of version control,
consistently applies it, and exposes its full power to all users.
Perhaps that resembles an editor you know?  Not to mention that the
operation of "commit", basic to all version control, is implemented by
adding a link to the head of a singly-linked list.  Does that resemble
a programming language you've heard of?[5]

Now it's true that perhaps the majority of Emacs developers want a VCS
that just stays out of their way.  Bazaar and Mercurial are better
choices for that, it seems, but only if you restrict yourself to the
CLI.  But I think that that desideratum will be more than adequately
satisfied via Lisp interfaces to git[3].  OTOH, there is a large
contingent of Emacs developers whose preferred VCS is git for various
reasons.

Of course, I've long been a git advocate, so the above is a selective
account of the merits and demerits.  Nevertheless, HTH.

Footnotes: 
[1]  IMHO YMMV.

[2]  Which criticism I admit I have no sympathy for.  Of the plethora
of commands, I admit I use quite a few (16 = init, add, rm, mv,
commit, status, log, diff, pull, push, branch, checkout, reset, gitk,
tag, help) frequently, but I rarely use options other than -m and -F
to commit, -b to checkout, and -<number> to log.  I suppose you
noticed "help", well, (a) I advise people on git a lot and need to
refer to help for workflows I don't use, and (b) I grant that
infrequently used commands like rebase are indeed complex, but their
power more than justifies the time to refer to help.  But I suppose
that's just me. ;-)

     I think that one big problem is not the CLI per se, but that
people who have a non-git mental model of VCS have great trouble
making sense of the way branch, checkout, and reset interact.  Also,
many people dislike git's practice of counting versions "backward"
from HEAD rather than "forward" from the repository root.

[3]  You've heard of vc.el and magit, I suppose?

[4]  Rename and first-class directory support.

[5]  The analogy is not perfect, of course, because a cons can have
only one cdr, while to implement merges a git commit is allowed to
have multiple parents.