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

[David Kastrup <dak@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:

> 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

Shrug.  In a distributed version control system, numerical version IDs
don't make sense.  Letting them make sense again requires beating some
sort of unified meaning into the distributed version graph that is not
inherently there, exactly because it is a distributed version control
system.  Git does not try to do it.  Other distributed version control
systems do, resulting in failure modes and/or merge complications that
are not obvious to people to whom linear numberings are obvious.

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

CVS did not commit more than specified files.  So nothing new here.

> _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!

Well, the point of Git's separate staging area is that it breaks the
established practice on _purpose_, but not out of _malice_.  The
resulting behavior is convenient as well as logical, and it is strictly
local (so does not affect the repository state or workflow at all and
consequently is orthogonal to most web interfaces).  And it is part of
the reason that people prefer Git over other "established VCS practices
and mnemonics" since those other version control systems refuse making
stuff more convenient out of principle.

Splitting operations into index operations and repository operations
means that when you look at the repository history, the additional index
stuff available for making local work more convenient does not need to
get taken into account.

So Git has an additional toolbox for preparing commits before they enter
the repository.  Web interfaces concerned with the repository might
choose to do something entirely different.  Read-only interfaces do not
even need to know anything about it and its workflow.

You can sort-of bypass it by using "git commit -a" all the time.

-- 
David Kastrup