Re: Git mirrors

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

This isn't relevant to Emacs decision-making, but unwarranted
git-bashing is no more helpful to people thinking about what to use in
their own projects than bzr-bashing is.

Juanma Barranquero writes:

 > And, by that token, I woudn't tout git, which is IMO the less
 > user-friendly for a beginner. I'd go so far as to say that using git
 > would "mak[e] harder to access or contribute to Free projects hosted
 > by GNU", as compared to bzr

In actual practice, I don't think that's true.  Witness the complexity
of BzrForEmacsDevs on the Emacs wiki.

git does indeed offer more rope for getting yourself in trouble, but
as long as you stick to the script, the basic git repertoire is only
slightly more complex but substantially more powerful than the
equivalent set of commands for bzr.  That means that your git workflow
doesn't need to change as often or abruptly as a bzr workflow does
when your role in a project changes (eg, from patch submitter to
committer, or from typo fixer to feature creature).  And git has a
simple model of commit (an "annotated cons") and branch (basically a
named variable whose value is a list), which makes predicting
performance and adapting workflows easy, and understanding complex git
commands like rebase and filter-branch and submodule *relatively*
easy.

bzr on the other hand has rather quirky performance characteristics,
depending on exactly how the plethora of internal caches are
implemented.  And many advanced DAG manipulation commands are simply
not available at all, which constrains private workflows.  (Of course
these commands can't be used on published branches, so their absence
doesn't constrain cooperative workflows much if at all.)

From the beginner's point of view, what git suffers from is fanboys.
People who use git tend to fall in love with the technology.  They're
*terrible* teachers, because no matter what you're trying to do,
they're always showing you nano-second optimizations and arcane
incantations.  (Still sounds like Emacs Lisp, eh?)  And they're not
great at writing docs, either.  Reference manuals, yes.  HOWTOs, no.

git's model is especially well-adapted to Emacs.  I think that (had
git been selected) after a short period of anguished cries of "who
designed this UI anyway, I'd like to setcdr his metacarpals!", Emacs
people would be doing well as a group and advanced git users would be
all over the community helping people do cool things (both gitwise and
in their Emacs feature branches and packages).  And there doesn't seem
to be anybody here with huge expertise in bzr itself, only enough to
explain how to fit into the Emacs workflow. :-(

IMO FWIW.