Re: Unexpected git diff output during merge conflict

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

 



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.

Thanks!
Nick



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
>>  +merged-history-test
>>  +===================
>>  +
>>  +### 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.
>
> -Peff



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux