Jonathan del Strother <maillist@xxxxxxxxxxxxxx> writes:
> Say I have a file that started out with the following content :
>
> line1
> line2
> line3
> line4
>
>
> I create a branch, which deletes line2. Someone else's branch deletes line 3.
>
> When I merge those two branches, the conflict looks like :
>
> line1
> <<<<<<< HEAD:lines
> line3
> =======
> line2
>>>>>>>> SomeoneElse:lines
> line4
>
>
>
> Which in my cursory overview, looked an awful lot like the obvious
> merge resolution ought to be
>
> line1
> line3
> line4
Why? The obvious resolution would be:
line1
line4
as it is obvious that you do not want line2 and the other does not want
line3.
But that is only true if it is obvious to you. When you cannot remember
what each side did since they forked, there are two ways you can use to
understand the history better without resorting to graphical merge tools.
$ git log -p --merge <path>
which shows you the commits involved in the conflict, what they did, and
why they did what they did (of course, this assumes that your project
participant did their commits properly).
$ git checkout --conflict=diff3 <path>
This will add an extra block to the conflicted output to show the common
ancestor's version, after showing yours. The conflicts left in <path>
would look like this:
line1
<<<<<<< ours
line3
|||||||
line2
line3
=======
line2
>>>>>>> theirs
line4
which may make it clearer that you deleted line2 and they deleted line3.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
