Re: On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?]

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 31 Oct 2015 12:16:29 +0900
> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: Alan Mackenzie <acm@muc.de>, David Kastrup <dak@gnu.org>, joakim@verona.se,
> 	Emacs developers <emacs-devel@gnu.org>
> 
> [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.  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.

It is a known psychological fact that after using some tool for a long
time, people begin liking or even loving it, no matter how horrible
that tool is.  In fact, people become fond of even the most hideous
misfeatures of that tool.  Otherwise, how to explain that people loved
DCL?

The above is an example.  The truth is that "$VCS commit" committing
all the changes _is_ TRT.  Why? because all the other VCSes before and
after Git do that, and because that's what a mere human would expect.
(I've made me an alias to do just that.)

More generally, Git's main problem is that it breaks almost every
human habit gained with the other VCSes: instead of an easily
remembered numerical version IDs you have those inhuman hashes and the
HEAD^^^^ and {m,n} thingies, instead of being able to say "commit" and
commit the entire changeset you need "git add" first, etc. etc.
_That_ is the single most important problem with Git that begets all
the other problems in usability and user-friendliness: it doesn't give
a damn about established VCS practices and mnemonics, and breaks them
all one after another.  It does that consciously and on purpose.  And
after all that, it expects me to like it.  Ha!