Re: On the popularity of git

[Alan Mackenzie <acm@muc.de>]

Hello, Stephen.

On Sat, Oct 31, 2015 at 12:16:29PM +0900, Stephen J. Turnbull wrote:
> Yuri Khan writes:

>  > Mercurial’s and Bazaar’s cores, on the other hand, are much more
>  > complicated,

> +100  Both suffer badly from the Knuthian "root of all error".  The
> insane complexity of Bazaar internals is half of what killed Bazaar.
> (The other half, of course, is that almost all of its fans are like
> Alan -- the last thing that they want to do is study their VCS, which
> in combination with complexity preclude contribution -- and the rest
> are "paperwork" refuseniks, so their contributions are refused.[1])

Just to clarify, I've never been a fan of bzr.  It took me some trouble
to learn, but only a reasonable amount of trouble.  The biggest
hindrance there was the vagueness of their documentation - it seemed
almost scared to say exactly what the program did.  But the trouble of
learning bzr was an order of magnitude less than that for git.

No, I don't want to become a VCS expert (or, as you put it, "study" my
VCS).  I studied hg, and it fell into place, mentally, without trouble.
I just want to be a user, as one can quite easily be a user of hg or
bzr.  Being a user of git involves learning its internal structures.
(Note the people recently emphasising the internal representation of a
git branch to me, talking about pointers to its tip, and so on.  I
really don't want to have to know about such stuff.)

It is evident that when the UI for git was "designed" nobody of any
experience (or taste) in UIs was involved in the process.  Nobody knew
when to say "stop!".  So there are _lots_ of commands, and the ones used
most often have 20, 30, 50 options to learn about, some of which do
several distinctly different things (e.g. git checkout).  A typical hg
command has, perhaps 4 or 5, or even 10.

If the git team had paid as much attention to UI as they did to elegant
internal structures, they would have had a world beater of a program.

> That doesn't seem to prevent Mercurial from being actively developed,
> though.

>  > and user-friendly UI (if any) is not sufficient to redeem them.

> +1

> I wouldn't go so far as to say "if any", but in my daily use, I find
> that even though git starts out with a handicap (3 letters vs. 2 for
> "hg"), I type fewer characters with git than with Mercurial.[2]  git is
> more likely to DTRT for me without options than is Mercurial.  I
> suspect that is true for enough users to make the "complexity of UI"
> argument sort of miss the point.

Not at all.  There are 20, 30, or 50 options which all consciously have
to be omitted.  Otherwise you are stumbling in the dark, or merely
learning sequences of commands by rote (as I have done), rather than
truly mastering them.

[ .... ]

> [2]  It occurs to me that one of the things I hated about both bzr and
> hg was that a bare "$VCS commit" commits everything.

But in both of them, the commit message template informed you which
files were being committed, giving you the opportunity to abort.

> That is *almost never* TRT for my workflow.  But I suspect that Alan
> loves that feature, since he has a religious objection to commiting a
> workspace that hasn't been polished to an optically perfect surface.

What, you mean as opposed to committing any old rubbish at the drop of a
hat?  No, that feature doesn't bother me one way or the other.  The
vagueness and uncertainty introduced by git's two stage committing, on
the other hand, is much unloved by me.

-- 
Alan Mackenzie (Nuremberg, Germany).