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

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

 



Piotr Krukowiecki <piotr.krukowiecki@xxxxxxxxx> writes:

> There's a conflict during the cherry-pick. git status shows:
>
> $ git status
> # On branch 9_0
> # Unmerged paths:
> #   (use "git add/rm <file>..." as appropriate to mark resolution)
> #
> #	both modified:      etc/file
> #
> no changes added to commit (use "git add" and/or "git commit -a")

Correct.  The commit you are applying the change with cherry-pick has
etc/file different from the parent of the commit being cherry-picked, and
the commit being cherry-picked also has it different, hence "both
modified".

> git diff shows a lot of changes:
> ...

Again correct; it is showing the mechanical (half)merge result so that you
know where you had overlapping changes.  The comparison between an
unmerged index and the working tree shows the changes in the file in the
working tree with respect to both versions (the one in the commit you are
on, and the other one in the commit you are cherry-picking), omitting
parts that the file in the working tree match one of the versions.  This
is how you don't have to see any part of the file that was trivially
merged in the output.

> If I edit the file and remove the "<<<< HEAD" marked and code
> between "===" and ">>>"  then
>
> 1. git status shows there are unmerged files:
>
> $ git status
> # On branch 9_0
> # Unmerged paths:
> #   (use "git add/rm <file>..." as appropriate to mark resolution)
> #
> #	both modified:      etc/file
> #
> no changes added to commit (use "git add" and/or "git commit -a")

Correct; until you "git add" to mark the conflict resolved, the path is
unmerged (do not ignore instructions in parentheses).

> 2. git diff shows nothing:
>
> $ git diff
> diff --cc etc/file
> index 815c28f,b8a48da..0000000
> --- a/etc/file
> +++ b/etc/file

Again, correct.  Read the description above on the "git diff" output.  At
this point, you removed the parts that came from one side (cherry-picked
side) by removing the lines between "===" and ">>>", so the lines in the
file in the working tree around that place match the other side (the one
in the commit you are on).  There is no block of lines that do not match
one of the sides, so there is no combined diff to show.

> 3. git diff --cached shows error? warning? info?
>
> $ git diff --cached
> * Unmerged path etc/file

Correct.  It is showing that you haven't run "git add" to resolve the
path, so it still is unmerged.

> 4. When I git add the file then git status, git diff, git diff
> --cached shows nothing:

Correct.  "git diff" is about comparing between the version in the index
you recorded with "git add" and the file in the working tree, so there is
nothing to show.  "git diff --cached [HEAD]" compares the index and the
HEAD, and it is understandable the result in the index matches HEAD if you
discarded what came from the cherry-pick before step 1.

> 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.
--
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


[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]