git apologia [was: git pull fails with merge conflicts. ...]

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

Eli Zaretskii writes:

 > I think we have different notions of "semantics", see below.
 > 
 > >                 commit ~ cons (object), tree ~ array of tree-or-blob,
 > > blob ~ atom, ref ~ list-valued symbol, branch = ref where the commit
 > > command has push (cl-macro) semantics, tag = ref where the commit
 > > command has cons (primitive function) semantics.  Everything else
 > > follows from list-traversing semantics, rather than the array
 > > reference semantics that svn and bzr provide with refnos.  Only merges
 > > ("cons with multiple parents") fail to follow the pattern, but I've
 > > never heard anyone complain that merges are particularly hard to
 > > understand.[1]
 > > 
 > > What's so hard about list semantics for an Emacs developer?
 > 
 > First, your list of primitive objects is already an obstacle: it's too
 > long,

It's *all* of the ones that matter.  You can ignore the internal
structure of trees.  And only "ref" is primitive, "tag" and "branch"
are derived from "ref".

But most important, as an Emacs developer, you understand how conses
work, and how to manipulate a Lisp list using car and cdr and push.
So you don't need to study "git semantics" *at all*, because you
already have a wealth of experience with them, once you grasp the
(very accurate) analogy.

 > As a user of a VCS, I care about commits, branches, and merges, and
 > my notion of a "tree" is just what I see in the file system.  I
 > don't want to know about anything else,

[...]
 > Second, too many things in Git are different, or are done differently,
 > or have different effect from their namesakes in other VCSes
 > (a.k.a. "have different semantics".

"<program> <command> has different semantics" is not what I understand
when someone says "I don't understand <program>'s semantics."

But OK, yes, that's an issue users would (justifiably) rather not deal
with.  If that's all you meant by "don't understand git semantics",
you have my sympathy, but I think the majority of Emacs developers are
going to be very pleased by the efficiency and power of git, and even
you may find after a few months that vc and/or magit have improved to
the point where you don't have to deal with git CLI at all any more.

A few random comments:

 > The result is that I'm not even sure I figured out the "@~n..@~m"
 > spec correctly (did I?).

You did.

 > The other result is that to see the diffs of the last commit, it is
 > much easier to use "git show" than the more obvious "git diff".

"git diff <commit>" has historical, and useful, semantics.  IMHO,
"git show <commit>" is a surprisingly elegant UI for what it does,
considering that this is git. :-)

Sure, they *could* have implemented "git diff -c" as hg and bzr do,
but I like "git show" better.  YMMV.

 > > Granted, submodules *are* hard; it's not just that tree is
 > > generalized to array of tree-or-blob-or-commit, but that commits
 > > also change semantics when used in submodules.  But we're not
 > > talking about submodules in Emacs yet.
 > 
 > I think we are, in the ELPA related discussions.  But maybe I'm
 > confused about that, too.

Ah, you're not confused.  There's been hot air vaporing about.  But I
don't think anybody who matters (= Stefan) is serious about it yet.

And rightly so.  The semantics of submodules are very subtle.  We use
hg subrepos in the XEmacs package repository, and it's a continuing
source of issues.  It's quite manageable, but mostly because we're a
very tight[1] community, and have a single package release manager
responsible for curating them.  I would expect much more trouble, at
least initially, in ELPA, because of the number and variety of package
maintainers, and individual maintainers in ELPA are responsible for
some things that Norbert takes care of for all XEmacs packages.

Footnotes: 
[1]  Read "small", but don't tell anyone I said that. :-)