Re: VC mode and git

[Eli Zaretskii <eliz@gnu.org>]

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

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

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?

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.

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

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