Re: cherry-pick applies some other changes than the specified one?

[Piotr Krukowiecki <piotr.krukowiecki@gmail.com>]

W dniu 21.03.2011 17:41, Johannes Sixt pisze:
> Am 3/21/2011 17:09, schrieb Junio C Hamano:
>> Piotr Krukowiecki <piotr.krukowiecki@gmail.com> writes:
>>> But when I take a different approach, and in addition to this:
>>>
>>>> If I edit the file and remove the "<<<< HEAD" marked and code
>>>> between "===" and ">>>"  then
>>>
>>> I also manually add the "+line" which is the change done in the cherry-picked
>>> commit, git diff shows a lot of other changes in unrelated lines
>>> (which lie close
>>> but still were not modified by the patch, nor were shown previously by
>>> git diff).
>>>
>>> This is very weird.
>>
>> Sorry, I have no idea what you are talking about.

I hoped someone might have some clues :)

 
> Assuming you did not 'git add' the file yet, you are looking at the
> "condensed combined diff" after manually resolving the conflict by doing
> the "+line" manually that the cherry-pick should have brought in. Of
> course, a lot of context is visible here if both sides have diverged
> considerably in this area.
> 
> I.e. the diff will look something like
> 
>  +line from HEAD
>  +line from HEAD
> + line from cherry-picked
>  +line from HEAD
> ...
> 
> Notice the double columns before the content lines. This sort of diff
> extens above and below the conflicting section until there is a "gap" of 3
> lines that changed neither on the HEAD side nor on the cherry-picked side
> since the merge base.

Hm that might be possible! I'll check it tomorrow @work.

If that's the case here is what got me lost:

As I wrote earlier, after removing the "<<<< HEAD" and code between "===" 
and ">>>", the git-diff showed nothing. So the natural impression was
"my files does not have any changes in working tree".

But then when I have added one line and did the diff again, it suddenly
started showing some other changes, unrelated to the added line or to
the cherry-picked commit.
 
I might have misses the double columns in the diff output so I though
it's just normal diff.

Thanks to your and Junio explanation I now understand why it works like
that.

I think I even suspected this might have something to do with the merge
conflict and tried to make git-diff show me exact change between working
tree and index/HEAD (ignoring the merge), so I can verify the file indeed
only have the change I did, but I could not find such option.
Does it exists? 


-- 
Piotr Krukowiecki