development/git
development/git
1
0
Fork 0
mirror of https://github.com/git/git synced 2024-07-17 02:57:48 +00:00
Code Issues Actions 9 Packages Projects Releases Wiki Activity

git-merge documentation: describe how conflict is presented

Browse source 
We took it granted that everybody knows how to read the RCS merge style
conflicts, and did not give illustrations in the documentation.  Now we
are introducing an alternative output style, it is time to document this.

The lack of illustration has been bugging me for a long time.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
This commit is contained in:
Junio C Hamano 2008-08-31 20:36:32 -07:00
parent eac5a40151
commit 70a3f89733
1 changed files with 65 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

65
Documentation/git-merge.txt
View file

@ -119,6 +119,71 @@ When there are conflicts, these things happen:
same and the index entries for them stay as they were,
i.e. matching `HEAD`.
HOW CONFLICTS ARE PRESENTED
---------------------------
During a merge, the working tree files are updated to reflect the result
of the merge. Among the changes made to the common ancestor's version,
non-overlapping ones (that is, you changed an area of the file while the
other side left that area intact, or vice versa) are incorporated in the
final result verbatim. When both sides made changes to the same area,
however, git cannot randomly pick one side over the other, and asks you to
resolve it by leaving what both sides did to that area.
By default, git uses the same style as that is used by "merge" program
from the RCS suite to present such a conflicted hunk, like this:
------------
Here are lines that are either unchanged from the common
ancestor, or cleanly resolved because only one side changed.
<<<<<<< yours:sample.txt
Conflict resolution is hard;
let's go shopping.
=======
Git makes conflict resolution easy.
>>>>>>> theirs:sample.txt
And here is another line that is cleanly resolved or unmodified.
------------
The area a pair of conflicting changes happened is marked with markers
"<<<<<<", "=======", and ">>>>>>>". The part before the "=======" is
typically your side, and the part after it is typically their side.
The default format does not show what the original said in the conflicted
area. You cannot tell how many lines are deleted and replaced with the
Barbie's remark by your side. The only thing you can tell is that your
side wants to say it is hard and you'd prefer to go shopping, while the
other side wants to claim it is easy.
An alternative style can be used by setting the "merge.conflictstyle"
configuration variable to "diff3". In "diff3" style, the above conflict
may look like this:
------------
Here are lines that are either unchanged from the common
ancestor, or cleanly resolved because only one side changed.
<<<<<<< yours:sample.txt
Conflict resolution is hard;
let's go shopping.
|||||||
Conflict resolution is hard.
=======
Git makes conflict resolution easy.
>>>>>>> theirs:sample.txt
And here is another line that is cleanly resolved or unmodified.
------------
In addition to the "<<<<<<", "=======", and ">>>>>>>" markers, it uses
another "|||||||" marker that is followed by the original text. You can
tell that the original just stated a fact, and your side simply gave in to
that statement and gave up, while the other side tried to have a more
positive attitude. You can sometimes come up with a better resolution by
viewing the original.
HOW TO RESOLVE CONFLICTS
------------------------
After seeing a conflict, you can do two things:
* Decide not to merge. The only clean-up you need are to reset