Re: Unexpected cherry-pick behaviour

From: Antoine Pelisse <apelisse@gmail.com>
Date: Dec 14, 2013, 09:40 UTC
Message-ID: <CALWbr2y1YDX0dzjpZoF8WL4+ND+8drurH+Wrf1wBs_-=0datOA@mail.gmail.com>
In-Reply-To: <beee32a53ece8b839578703deb851eaa@matos-sorge.com>

On Wed, Dec 11, 2013 at 12:19 PM, Paulo Matos <paulo@matos-sorge.com> wrote:

Show 20 quoted lines

> On 11/12/2013 11:09, Antoine Pelisse wrote:
>>>
>>>
>>> I don't know how to interpret the fact that the line you sent (with the
>>> obvious --conflicts being --conflict) outputs nothing...
>>
>>
>> That is expected. git-checkout with this option [1] will reset the
>> conflict on gcc/tree-ssa-threadedge.c file to the initial conflict
>> state, and use the diff3 markers. You should have a new look at that
>> file as you will now be able to see the "ancestor" in the conflict.
>>
>> [1] You can have a look either at git-checkout manpage or here:
>> http://git-scm.com/docs/git-checkout, especially --merge and
>> --conflict options.
>> --
>
>
> Got it, but still not helpful as git is still modifying code out of the
> conflicting zone.

Actually it didn't modify out of the conflicting zone. This is because you are having a look at a combine-diff which tries to show both how it changed master *and* the cherry-picked patch at the same time. If you only want to see the diff applied to master, you should run:

    $ git diff --ours

You can also have a look at what is currently being applied:

    $ git diff :1:gcc/tree-ssa-threadedge.c :3:gcc/tree-ssa-threadedge.c

By the way, does anybody know a better way to do that ? I happen to do that quite a lot when fixing complex conflicts and the command is quite inconvenient (I always end-up forgetting which numbers to use, etc..).

Hope that helps, Antoine