Skip to content

Commit 70a3f89

Browse files
committed
git-merge documentation: describe how conflict is presented
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>
1 parent eac5a40 commit 70a3f89

File tree

1 file changed

+65
-0
lines changed

1 file changed

+65
-0
lines changed

Documentation/git-merge.txt

Lines changed: 65 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -119,6 +119,71 @@ When there are conflicts, these things happen:
119119
same and the index entries for them stay as they were,
120120
i.e. matching `HEAD`.
121121

122+
HOW CONFLICTS ARE PRESENTED
123+
---------------------------
124+
125+
During a merge, the working tree files are updated to reflect the result
126+
of the merge. Among the changes made to the common ancestor's version,
127+
non-overlapping ones (that is, you changed an area of the file while the
128+
other side left that area intact, or vice versa) are incorporated in the
129+
final result verbatim. When both sides made changes to the same area,
130+
however, git cannot randomly pick one side over the other, and asks you to
131+
resolve it by leaving what both sides did to that area.
132+
133+
By default, git uses the same style as that is used by "merge" program
134+
from the RCS suite to present such a conflicted hunk, like this:
135+
136+
------------
137+
Here are lines that are either unchanged from the common
138+
ancestor, or cleanly resolved because only one side changed.
139+
<<<<<<< yours:sample.txt
140+
Conflict resolution is hard;
141+
let's go shopping.
142+
=======
143+
Git makes conflict resolution easy.
144+
>>>>>>> theirs:sample.txt
145+
And here is another line that is cleanly resolved or unmodified.
146+
------------
147+
148+
The area a pair of conflicting changes happened is marked with markers
149+
"<<<<<<", "=======", and ">>>>>>>". The part before the "=======" is
150+
typically your side, and the part after it is typically their side.
151+
152+
The default format does not show what the original said in the conflicted
153+
area. You cannot tell how many lines are deleted and replaced with the
154+
Barbie's remark by your side. The only thing you can tell is that your
155+
side wants to say it is hard and you'd prefer to go shopping, while the
156+
other side wants to claim it is easy.
157+
158+
An alternative style can be used by setting the "merge.conflictstyle"
159+
configuration variable to "diff3". In "diff3" style, the above conflict
160+
may look like this:
161+
162+
------------
163+
Here are lines that are either unchanged from the common
164+
ancestor, or cleanly resolved because only one side changed.
165+
<<<<<<< yours:sample.txt
166+
Conflict resolution is hard;
167+
let's go shopping.
168+
|||||||
169+
Conflict resolution is hard.
170+
=======
171+
Git makes conflict resolution easy.
172+
>>>>>>> theirs:sample.txt
173+
And here is another line that is cleanly resolved or unmodified.
174+
------------
175+
176+
In addition to the "<<<<<<", "=======", and ">>>>>>>" markers, it uses
177+
another "|||||||" marker that is followed by the original text. You can
178+
tell that the original just stated a fact, and your side simply gave in to
179+
that statement and gave up, while the other side tried to have a more
180+
positive attitude. You can sometimes come up with a better resolution by
181+
viewing the original.
182+
183+
184+
HOW TO RESOLVE CONFLICTS
185+
------------------------
186+
122187
After seeing a conflict, you can do two things:
123188

124189
* Decide not to merge. The only clean-up you need are to reset

0 commit comments

Comments
 (0)