Re: VC mode and git

[Alan Mackenzie]

Hello, Sergey.

On Wed, Apr 01, 2015 at 12:28:25PM +0300, Sergey Organov wrote:
> Alan Mackenzie <address@hidden> writes:

> >>  > Part of the problem is that the git-merge man page doesn't say that
> >>  > it messes with the working tree

> >> What else would it do?  Merge tools have changed the working tree from
> >> time immemorial.

> > That's poor, Stephen.  It might well merge in the repository without
> > touching the working tree.  The fact is, the documentation doesn't say
> > this - it doesn't even say where the two sources for its merge come from,
> > or where it puts the result.

> That's pure insinuation. Git documentation could be far from ideal, but
> it has most of information there. Here is quote from Git manual page on
> merge for you. It mentions what merge does to working tree 4 times, and
> tells you exactly where it puts the two sources of conflicting merges:

Exaggeration rather than insinuation, I think you mean.  The git
documentation is very bad.  The information may be there, but if it is
buried deep down in the small print, it is not useful.  We're not talking
about arcane details here, we're talking about the basic functionality -
what git merge actually does - what does it merge and where does it put
the result?

It's worth saying that the excerpt you quote below is at approximately
line 170 inside the man page.  If this is typical of git man pages, then
it would seem I have to read, say, ~200 lines of each of 20 or 30 man
pages to find the basic functionality of each command.

> [QUOTE=git help merge]

> TRUE MERGE
>        Except in a fast-forward merge (see above), the branches to be merged
>        must be tied together by a merge commit that has both of them as its
>        parents.

>        A merged version reconciling the changes from all branches to be merged
>        is committed, and your HEAD, index, and working tree are updated to it.
>        It is possible to have modifications in the working tree as long as
>        they do not overlap; the update will preserve them.

>        When it is not obvious how to reconcile the changes, the following
>        happens:

>         1. The HEAD pointer stays the same.

>         2. The MERGE_HEAD ref is set to point to the other branch head.

>         3. Paths that merged cleanly are updated both in the index file and in
>            your working tree.

>         4. For conflicting paths, the index file records up to three versions:
>            stage 1 stores the version from the common ancestor, stage 2 from
>            HEAD, and stage 3 from MERGE_HEAD (you can inspect the stages with
>            git ls-files -u). The working tree files contain the result of the
>            "merge" program; i.e. 3-way merge results with familiar conflict
>            markers <<< === >>>.

>         5. No other changes are made. In particular, the local modifications
>            you had before you started merge will stay the same and the index
>            entries for them stay as they were, i.e. matching HEAD.

>        If you tried a merge which resulted in complex conflicts and want to
>        start over, you can recover with git merge --abort.

> [/QUOTE]

> P.S. You sound like pure Git hater most of times. Haters will hate.
> No matter what.

That's an uncalled for ad hominem.  I could equally well call you a git
lover, somebody who will love git to the end, deliberately remaining
oblivious to its many problems.  I do not hate, full stop.

I dislike git strongly because it has cost me and continues to cost me an
inordinate amount of time and effort to learn and use.  The vagueness and
general badness of its documentation is a large part of this.

> -- Sergey.

-- 
Alan Mackenzie (Nuremberg, Germany).