Re: VC mode and git

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

Eli Zaretskii writes:
 > > From: "Stephen J. Turnbull" <stephen@xemacs.org>
 > > Cc: Sergey Organov <sorganov@gmail.com>,
 > >     emacs-devel@gnu.org
 > > Date: Fri, 03 Apr 2015 07:40:40 +0900
 > > 
 > > Eli Zaretskii writes:
 > >  > > From: Sergey Organov <sorganov@gmail.com>
 > > 
 > >  > > Each commit has zero or more pointers to parents, usually 1. Merge
 > >  > > commit is commit that has more pointers to parents than 1 (usually 2).
 > >  > > That's all about the meta-data. Simple, eh?
 > >  > 
 > >  > And that meta-data needs to be brought in as part of the merge, in
 > >  > addition to changes to the tree.
 > > 
 > > No.  That's an important difference between git and other DVCSes.
 > > "git merge" does a 3-way merge in a tree that corresponds to a
 > > previously committed state, and sets up some (hidden) metadata that
 > > help automate the following multi-parent commit.  Optionally it will
 > > initiate that commit.
 > > 
 > > The meta-data must already be present in the repo pointed to by the
 > > workspace, brought in by a fetch.  Because it's a very common
 > > operation, especially in synchronizing mirror repos, git pull will
 > > automatically fetch and merge.  Perhaps that what you think about it.
 > 
 > I know all of the above, and I don't see where it contradicts what I
 > wrote.

You wrote "the meta-data needs to be brought in".  That's simply
false; when git merge is invoked, the meta data must already be
present or you will get an "unknown commit" error.  You're trying to
argue that a merge (and similarly for commit) is something more than
it is.  It isn't in git, although it is in bzr and hg, and it's
something rather different again from either in Darcs.  This is just
going to lead to more confusion on the part of those who think git
"should" be something different than it is.
 
 > The original issue was a claim that a merge (as an operation) is "just
 > a commit", and I said it's more than that.

Sergey (at least as quoted above) wrote "merge commit", so technically
it *is* just a commit.

But in any case, your "more than that" so far is pure hand-waving, not
supported by the actual semantics of "git merge," "git commit," or the
commit object.  This is more your list than mine, I'm happy to use your
terminology.  But I refuse to accept "it's more than that" as a
definition.

 > My terminology follows the Git glossary man page, which I think
 > doesn't agree with the above, at least not 100%.  E.g., "commit",
 > neither as a noun nor as a verb, is not described there as "creating a
 > commit object".

Are you looking at the same glossary entry I am?  It says (and I quote
in full so there can be no confusion):

       commit

           As a noun: A single point in the Git history; the entire
           history of a project is represented as a set of
           interrelated commits. The word "commit" is often used by
           Git in the same places other revision control systems use
           the words "revision" or "version". Also used as a short
           hand for commit object.

           As a verb: The action of storing a new snapshot of the
           project's state in the Git history, by creating a new
           commit representing the current state of the index and
           advancing HEAD to point at the new commit.

The "verb" describes exactly "creating a commit object", using the
shorthand of "commit" for "commit object" described in the noun
section.  The additional semantics you pull in are simply not there at
all, except in a reference to "same places other VCSes" use different
words that is so vague it makes me cringe.

Note that you can't even claim that there's a need to collect meta
data for the tree; that's *already* in the index in principle (ie, if
you use "git add <file>; git commit" instead of the shorthand "git
commit <file>").

You can quibble a bit, for example, you can claim that "git commit
<file>" is more fundamental than I claim above.  But I don't see much
room for anything more than "you may need to create a tree object a
well as a commit object."  If you want to claim there are additional
semantics, I see no alternative except that you define them
explicitly, as I requested above.