Re: Unexpected git diff output during merge conflict
- Date: Thu, 8 Feb 2018 11:50:08 +0000
- From: "Nick O'Leary" <nick.oleary@xxxxxxxxx>
- Subject: Re: Unexpected git diff output during merge conflict
Ah, the whitespace that was added to enable the >>> markers to be
added... that makes sense.
Which means the output is correct and some assumptions my code makes
about the format of the Combined Diff are wrong.
On 8 February 2018 at 11:25, Jeff King <peff@xxxxxxxx> wrote:
> On Thu, Feb 08, 2018 at 10:51:57AM +0000, Nick O'Leary wrote:
>> $ git diff README.md
>> diff --cc README.md
>> index 61d78b2,620d806..0000000
>> --- a/README.md
>> +++ b/README.md
>> @@@ -1,7 -1,1 +1,11 @@@
>> -This is my default readme
>> ++<<<<<<< HEAD
>> +### About
>> +This is your project's README.md file. It helps users understand what your
>> - project does, how to use it and anything else they may need to know.
>> ++project does, how to use it and anything else they may need to know.
>> ++This is my default readme
>> ++>>>>>>> dev
>> This does not look right to me. The 'This is my default readme' line
>> has ++ at the start - suggesting its new to both parent copies of the
>> file, which isn't the case - it came from the dev branch so should be
>> prefixed with '+ '.
>> I'm also not clear why the line beginning 'project does' has both a -
>> and ++ prefix.
> Are you sure there aren't whitespace differences in those two lines?
> For instance, if I do:
> # base commit
> git init
> git commit --allow-empty -m base
> # one side; note missing newline!
> printf 'this is my default readme' >file
> git add file
> git commit -m default
> # other side
> git checkout -b other HEAD^
> echo this is a longer
> echo and more involved
> echo README
> } >file
> git add file
> git commit -m longer
> # and now merge and get a conflict
> git merge master
> Then I get similar output to you. The content with merge-conflicts
> can't represent the original lack-of-newline for that file, because of
> course there's another ">>>" line after it.
> If I swap out the printf for echo, adding the newline, then it produces
> the output you'd expect.