Re: VC mode and git

[Eli Zaretskii <eliz@gnu.org>]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: sorganov@gmail.com,
>     emacs-devel@gnu.org
> Date: Fri, 03 Apr 2015 17:00:42 +0900
> 
> 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.

Irrelevant: we are not talking about the invocation of "git merge".
See the glossary, under "merge" for what it includes.

> You're trying to argue that a merge (and similarly for commit) is
> something more than it is.

See the glossary: a (successful) merge _results_ in a commit, but
that's not what it _is_.  (Should I quote Lewis Carrol's immortal
piece about the difference between the name of a thing and the thing
itself?)

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

Alan was interested in what the merge does, so talking about a "merge
commit" is changing subjects.

I'm saying that trying to explain to newbies what a merge does by
being "technically correct" is not helpful.  I don't even understand
all this attitude: do we want Git newbies to become more proficient in
using Git, or do we want to just humiliate them by pointing out how
little they know?  If the former, why do we insist on being
"technically correct" instead of explaining things in a way they could
be understood?

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

Complain to the writers of the Git glossary, then.  I just read what
they say there.

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

No, it is described as "the action of storing a new snapshot of the
project's state in the Git history by creating a commit object and
advancing HEAD to point at the new commit".  By selectively omitting
the parts of this description, you make it sound like I said
something incorrect, which is false.

> using the shorthand of "commit" for "commit object" described in the
> noun section.

I already said that using shorthands in this discussion only increases
confusion, and is not helpful to newbies who strive to understand a
complex subject.

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

READ THE GLOSSARY UNDER "MERGE"!!  It clearly says that the merge
action _includes_ bringing that data.

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

I'm just following the glossary, no more, no less.