[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: VC mode and git

From: Sergey Organov
Subject: Re: VC mode and git
Date: Wed, 01 Apr 2015 12:28:25 +0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)

Alan Mackenzie <address@hidden> writes:

> Hello, Stephen.
> On Tue, Mar 31, 2015 at 11:02:16PM +0900, Stephen J. Turnbull wrote:
>> Alan Mackenzie 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:

[QUOTE=git help 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

       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

        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.


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

-- Sergey.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]