Re: VC mode and git

[Sergey Organov <sorganov@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Sergey Organov <sorganov@gmail.com>
>> Date: Wed, 01 Apr 2015 16:03:26 +0300
>> Cc: emacs-devel@gnu.org
>> 
>> > Exaggeration rather than insinuation, I think you mean.
>> 
>> I said what I meant: insinuation.
>
> I think you were wrong.
>
>> If you are not interested in details, the manual page explains what
>> merge does and where it puts result in the first sentence of the
>> description:
>> 
>> "Incorporates changes from the named commits (since the time their
>> histories diverged from the current branch) into the current branch."
>
> Good luck understanding this when learning what merge does in Git!
> Starting from the "branch" thingy, which, as you will read everywhere
> is just a pointer to the HEAD commit.  So what does it mean to
> "incorporate changes in the current branch", if the branch is just a
> pointer?

Yes, a pointer that moves to point to new commit automatically every
time you commit on the branch. Incorporating changes means the same
thing every time: commit. What's new or unusual about it?

> And then there's "histories diverged" part, of course, that is never
> explained.

Yeah it's total mystery to everybody. If one is so novice that she has
no idea about "history diverged" thingy, she should really start from
some basic tutorial, not from reading "git merge" manual page.

> And finally, even if you succeed in negotiating these obstacles,
> there's still the important question: what does it mean to
> "incorporate in the branch"? what does it change, and in what order?

Basically, it means exactly what it says: your changes from divergence
point to the named commit will now be there in the current branch.

The details are explained later in the same manual page, as they depend
on different modes of operation.

> Of course, if you already know how merge works in Git, have merged
> your own branches several times, and had your share of mistakes until
> you finally got it -- then this text will speak volumes to you.  But
> that's not what Alan complained about.

In this particular case he said utter lie about particular git manual
page. It's useless to deny that. That was the only reason I had to
intervene.

>> >> > Part of the problem is that the git-merge man page doesn't say that
>> >> > it messes with the working tree
>> 
>> Oh, really? Anybody who doesn't actively avoid to understand anything
>> "git" will easily infer that the working tree should be updated
>> accordingly, as "the current" is those branch that working tree
>> reflects, by definition.
>
> Oh, really?  You mean merge doesn't work, or is a no-op, in a "bare"
> repository, where there's no tree?

[(BARE:master)]$ git merge v3.6
fatal: This operation must be run in a work tree
[(BARE:master)]$

But it's even irrelevant. One needs to have work tree to care about
changes to work tree, that excludes bare repositories from discussion.

> Give up!  Git's documentation "needs work" (TM).  It's futile to try
> to refute that.

Nobody refutes it. Any documentation needs work (TM). Git's needs work.
It does not mean that spreading misinformation about its current state
is acceptable.

-- Sergey.