Re: On the popularity of git

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

Alan Mackenzie writes:

 > 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.

Weird.  I studied all three (in order to help write PEP 374), and they
just aren't different for any of the Python-Dev workflows that we
compared.  At the time it took 0.1 revolutions of Halley's Comet to
checkout Python with bzr; obviously that was out.  The people who just
hated git but couldn't explain why, plus the dogfooding principle (hg
is written in Python), carried the day.

 > 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.

No, it doesn't.  The workflows for git looked just like the workflows
for hg and bzr, *unless you want to modify a DAG at internal nodes*
(but there were no such tasks on the list for PEP 374).  Then the
workflows are very different (basically nonexistent in hg and bzr at
that time).

In any case, you already know the internal structure of git because
it's the same as a Lisp list (with a slight variation to account for
merges).  The commands for working with it have different names
(commit for cons, reset for setq), that's all.

 > (Note the people recently emphasising the internal representation
 > of a git branch to me, talking about pointers to its tip, and so
 > on.

Yeah, and a year ago I would have been posting the same stuff.  I know
now that that's like "messing around with Jim"[1], because:

 > 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

Sounds just like Emacs, except that git is a whole lot more popular.

 > to learn about,

Huh?  If you don't want to learn about them, don't.  Ask a friend who
uses git how to do it.  You do have git-using friends (probably about
100,000 of them -- all them cc-mode users!)

 > some of which do several distinctly different things (e.g. git
 > checkout).

OK, you got me there.  You have a choice: learn all the variations on
checkout, or learn some internals so you can use reset.  Not attractive.

 > 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.

Er, where have you been for the last 5 years?  They *do* have a world
beater of a program.  Compare user population with, uh, Emacs.

 > Not at all.  There are 20, 30, or 50 options which all consciously have
 > to be omitted.

Which 6 letters in the word "option" didn't you read as you typed it?
Come on, Alan, you've gone past petulant with that one.

I really don't get this; in my workflow I almost never use options in
git, except for -<digits> for log, -m and occasionally -a when
committing, --hard for reset, -l and -f for tag and branch, and -b for
checkout, all of which have important semantics and are pretty easy to
understand IMO.  What other git options do you need for your workflows?

 > > [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.

I never see that template: I use "-m" (command line) or "-F ,msg" (in
XEmacs).

 > > 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?

Yes.  Heck, I had this:

(defun sjt/git-auto-commit ()
  (let ((file (file-name-nondirectory (buffer-file-name))))
    (shell-command (format "git commit -m \"Auto-commit %s.\" %s"
			   file file))))

on after-save-hook for a while.  I admit it stopped being amusing
pretty quickly (rebase -i didn't exist back then). Instead, I just
taught myself to commit frequently enough that if I get confused about
what I'm doing I can usually reconstruct thought processes by looking
at the diffs.

BTW, although I don't care if those "interim" commits become public,
if I did care it's easy enough to "squash" the interim branch into a
single commit on trunk, and optionally delete that interim branch.

 > The vagueness and uncertainty introduced by git's two stage
 > committing,

I don't understand.  If you don't have any added or removed files for
your "polished" commit, you just do "git commit --all".  If you do,
you do "git add --all; git commit".  This isn't much different from
what you have to do with bzr or hg, except that you wouldn't need
--all on commit for the first version.  It's a bit more typing than
for hg or bzr which default to committing everything modified, but
that's always an issue when users disagree about defaults: the
minority loses.


Footnotes: 
[1]  https://www.youtube.com/watch?v=-4qUXcXuMSE