Re: VC mode and git

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > 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?)

No.  You should say what you mean, instead of telling others that
they're wrong and saying anything *but* what you mean.  "What you have
ment throughout" was well-expressed in your reply to Sergey when you
mentioned the branch-tracing operation which gives the commit that
contains the tree for the "base version" of a three-way merge.

 > I'm saying that trying to explain to newbies what a merge does by
 > being "technically correct" is not helpful.

Being technically *incorrect* is even less helpful.  Your answer to
Alan (indirectly via Sergey) that a merge (1) identifies a base
commit, (2) uses that and the trees of the two branch heads (usually)
to perform a 3-way merge, (3) collects the metadata (specifically, the
new tree and the parents), (4) assembles that into a commit which is
stored in the tree, and (5) advances HEAD of the current branch to
that commit is indeed useful, but from Alan's point of view you still
missed a crucial point, which is that git operates on *commits*, and
not directly on the workspace.  It is *convenient* to use the
workspace for the work (since you're going to check out the merged
tree there in the end), and that is the (technical) reason you need to
be committed up before merging.

 > I don't even understand all this attitude: do we want Git newbies
 > to become more proficient in using Git,

No, we want to support their efforts to become more productive using
git.  If they want to become proficient, I don't think there's any
problem.  But Alan and Richard have expressed a rather strong desire
to learn *nothing* about git, yet insist on workflows that are
infeasible if they remain ignorant of the details and options of git.
They can't have both; the first task is to make that clear, so that
they can make their own choice as to whether to become proficient in
git, or to adopt a workflow that is less than optimal according to
their opinions.

 > or do we want to just humiliate them by pointing out how little
 > they know?

That was uncalled for.

 > If the former, why do we insist on being "technically correct"
 > instead of explaining things in a way they could be understood?

Because it's entirely unclear to me what they are asking.  Richard
is incapable of describing what he actually did, yet bridles at any
suggestion that his actions were involved in messing things up
(despite repeated admissions that he forgot this or that).  Alan is
similar.  They profess ignorance of git but assert that it is a
"screw" and poorly designed.

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

OK, you are correct, it is more than creating a commit object.  It
also includes advancing HEAD.  How does that level of nitpicking
advance the cause of explaining to Alan what a commit is?

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

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

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

Why?  Here I was discussing "commit", which you also claim
(pedantically correct) is more than simply creating a commit object.

However, I did read it a couple of times, and with the exception of
your post to Sergey, I have no clue what you're talking about.

 > It clearly says that the merge action _includes_ bringing that
 > data.

Ah, with "merge", we have an English problem.  "Bring" and the other
words you have used to describe the *computation* of the merged tree
are inappropriate.  They correspond semantically to *fetch*.

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

Quite inaccurately, IMO, and while it doesn't matter who's "correct",
that *difference* matters, because when you refer to the glossary
without precise description of what you mean *in your own words*, I
understand something different from what you intend, and communication
fails.

You're perfectly capable of expressing yourself operationally; your
post to Sergey was beautiful, concise and accurate, and after reading
that I quite understood what you have been getting at the whole time.
I wish you would write more posts like that.  Your shouting about
"READ!  READ!" on the other hand, is totally useless.