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

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

[Piotr Krukowiecki]

Hi,

I'm cherry-picking one commint between branches. The commit is a simple
one-line addition, something like:

--- a/etc/file
+++ b/etc/file
@@ -2613,6 +2613,7 @@
line1
line2
+   line3
line4
line5


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")

git diff shows a lot of changes:

diff --cc etc/file
index 815c28f,b8a48da..0000000
--- a/etc/file
+++ b/etc/file
@@@ -2700,83 -2611,10 +2700,89 @@@
[...]
++<<<<<<< HEAD
 +    line
 +    line
[...]
++=======
+     here I basically can see what's code
+     look like in the commit I want to merge
++>>>>>>> c64e8ca...
       line
 +    line
[...]


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")

2. git diff shows nothing:

$ git diff
diff --cc etc/file
index 815c28f,b8a48da..0000000
--- a/etc/file
+++ b/etc/file

3. git diff --cached shows error? warning? info?

$ git diff --cached
* Unmerged path etc/file

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

$ git add etc/file
$ git status
# On branch 9_0
nothing to commit (working directory clean)
$ git diff
$ git diff --cached


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. I understand the information I provided was very scarce,
but does anyone know what could be happening?
Or do I have to try to reproduce this behaviour and post the steps to do so?

It might be somehow related to git-svn or git-new-workdir ...

-- 
Piotr Krukowiecki

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

[Junio C Hamano]

Piotr Krukowiecki <piotr.krukowiecki@gmail.com> 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.

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

[Johannes Sixt]

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.

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.

-- Hannes

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

[Piotr Krukowiecki]

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

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

[Junio C Hamano]

Piotr Krukowiecki <piotr.krukowiecki@gmail.com> writes:

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

Doesn't "git diff HEAD" show the difference between HEAD and working tree
without the higher stages for the path getting in the way?

The difference between the index and the working tree is "git diff" which
is condensed.  I think you can force it to uncondense it by giving "-c"
option, but I haven't tried (didn't find a need/use for it for a long
time).

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

[Piotr Krukowiecki]

W dniu 21.03.2011 20:47, Junio C Hamano pisze:
> Piotr Krukowiecki <piotr.krukowiecki@gmail.com> writes:
> 
>> 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).
> 
> Doesn't "git diff HEAD" show the difference between HEAD and working tree
> without the higher stages for the path getting in the way?

Forgot about this - usually commit defaults to HEAD if you didn't specify it.
My fault.

 
> The difference between the index and the working tree is "git diff" which
> is condensed.  I think you can force it to uncondense it by giving "-c"
> option, but I haven't tried (didn't find a need/use for it for a long
> time).

I think I tried it and it didn't work. It's also not described in git diff
man page.


-- 
Piotr Krukowiecki

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

[Jonathan Nieder]

Piotr Krukowiecki wrote:

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

Sure.  The index contains multiple competing versions, which you can
see with "git ls-files -u".  To compare the working tree and one of
those use "git diff --base / --ours / --theirs" (or -1 / -2 / -3).

To view changes relative to a particular commit, use "git diff <commit>".
For example, "git diff HEAD".  The git-diff(1) manpage (shown by
"git diff --help") explains.

Hope that helps,
Jonathan

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

[Piotr Krukowiecki]

W dniu 21.03.2011 20:58, Jonathan Nieder pisze:
> Piotr Krukowiecki wrote:
> 
>> 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? 
> 
> Sure.  The index contains multiple competing versions, which you can
> see with "git ls-files -u".  To compare the working tree and one of
> those use "git diff --base / --ours / --theirs" (or -1 / -2 / -3).

Thanks, didn't know about that (and it's not documented in diff man page).

 
> To view changes relative to a particular commit, use "git diff <commit>".
> For example, "git diff HEAD".  The git-diff(1) manpage (shown by
> "git diff --help") explains.
> 
> Hope that helps,
> Jonathan


-- 
Piotr Krukowiecki

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

[Junio C Hamano]

Piotr Krukowiecki <piotr.krukowiecki@gmail.com> writes:

>> Sure.  The index contains multiple competing versions, which you can
>> see with "git ls-files -u".  To compare the working tree and one of
>> those use "git diff --base / --ours / --theirs" (or -1 / -2 / -3).
>
> Thanks, didn't know about that (and it's not documented in diff man page).

These "compare a particular stage against working tree file" modes
only make sense when you are comparing the index and the working tree, so
the description is in "git diff-files" manpage but hasn't been ported to
the documentation of generic "git diff" frontend.

Perhaps we should.

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

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

>> Thanks, didn't know about that (and it's not documented in diff man page).
>
> These "compare a particular stage against working tree file" modes
> only make sense when you are comparing the index and the working tree, so
> the description is in "git diff-files" manpage but hasn't been ported to
> the documentation of generic "git diff" frontend.
>
> Perhaps we should.

And here is a quick attempt to do so.

This just leaves the details of what -c/--cc are about to the combined
diff format section in diff-generate-patch.txt, which I updated in the
separate patch.

 Documentation/diff-options.txt   |   31 +++++++++++++++++++++++++++++++
 Documentation/git-diff-files.txt |   19 -------------------
 Documentation/git-diff-tree.txt  |   20 --------------------
 3 files changed, 31 insertions(+), 39 deletions(-)

diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index c93124b..19ce302 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -24,6 +24,37 @@ ifndef::git-format-patch[]
 --patch::
 	Generate patch (see section on generating patches).
 	{git-diff? This is the default.}
+
+-1 --base::
+-2 --ours::
+-3 --theirs::
+-0::
+	These make sense only when comparing the index and the working
+	tree (i.e. `git diff-files` or `git diff <path>...`) and compares
+	against the "base" version, "our branch" or "their
+	branch" respectively.  With these options, diffs for
+	merged entries are not shown.
++
+The default is to diff against our branch (-2) and the
+cleanly resolved paths.  The option -0 can be given to
+omit diff output for unmerged entries and just show "Unmerged".
+
+-c::
+--cc::
+	Produce "combined diff" (and "dense combined diff" showing how the
+	result is different compared to more than one original.
++
+When used in showing a merge commit (i.e. `git show <merge>`, 
+`git diff-tree <merge>` or when feeding a merge commit
+to `git diff-tree --stdin`), compare the parent commits of the
+merge with the merge commit.
++
+When used in comparison between the index and the working tree
+(i.e. `git diff` during a conflicted merge or rebase),
+compare stage 2 (our branch), stage 3 (their
+branch) and the working tree file and outputs a combined
+diff.
+
 endif::git-format-patch[]
 
 -U<n>::
diff --git a/Documentation/git-diff-files.txt b/Documentation/git-diff-files.txt
index 8d48194..82d2e2e 100644
--- a/Documentation/git-diff-files.txt
+++ b/Documentation/git-diff-files.txt
@@ -21,25 +21,6 @@ OPTIONS
 -------
 include::diff-options.txt[]
 
--1 --base::
--2 --ours::
--3 --theirs::
--0::
-	Diff against the "base" version, "our branch" or "their
-	branch" respectively.  With these options, diffs for
-	merged entries are not shown.
-+
-The default is to diff against our branch (-2) and the
-cleanly resolved paths.  The option -0 can be given to
-omit diff output for unmerged entries and just show "Unmerged".
-
--c::
---cc::
-	This compares stage 2 (our branch), stage 3 (their
-	branch) and the working tree file and outputs a combined
-	diff, similar to the way 'diff-tree' shows a merge
-	commit with these flags.
-
 -q::
 	Remain silent even on nonexistent files
 
diff --git a/Documentation/git-diff-tree.txt b/Documentation/git-diff-tree.txt
index 4e5f127..ebcfcfb 100644
--- a/Documentation/git-diff-tree.txt
+++ b/Documentation/git-diff-tree.txt
@@ -88,26 +88,6 @@ include::pretty-options.txt[]
 	'git diff-tree' outputs a line with the commit ID when
 	applicable.  This flag suppressed the commit ID output.
 
--c::
-	This flag changes the way a merge commit is displayed
-	(which means it is useful only when the command is given
-	one <tree-ish>, or '--stdin').  It shows the differences
-	from each of the parents to the merge result simultaneously
-	instead of showing pairwise diff between a parent and the
-	result one at a time (which is what the '-m' option does).
-	Furthermore, it lists only files which were modified
-	from all parents.
-
---cc::
-	This flag changes the way a merge commit patch is displayed,
-	in a similar way to the '-c' option. It implies the '-c'
-	and '-p' options and further compresses the patch output
-	by omitting uninteresting hunks whose the contents in the parents
-	have only two variants and the merge result picks one of them
-	without modification.  When all hunks are uninteresting, the commit
-	itself and the commit log message is not shown, just like in any other
-	"empty diff" case.
-
 --always::
 	Show the commit itself and the commit log message even
 	if the diff itself is empty.

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

[Jonathan Nieder]

Junio C Hamano wrote:

> This just leaves the details of what -c/--cc are about to the combined
> diff format section in diff-generate-patch.txt, which I updated in the
> separate patch.

Thanks; this looks pretty good.  A few nitpicks:

> --- a/Documentation/diff-options.txt
> +++ b/Documentation/diff-options.txt
> @@ -24,6 +24,37 @@ ifndef::git-format-patch[]
>  --patch::
>  	Generate patch (see section on generating patches).
>  	{git-diff? This is the default.}
> +
> +-1 --base::
> +-2 --ours::
> +-3 --theirs::
> +-0::
> +	These make sense only when comparing the index and the working
> +	tree (i.e. `git diff-files` or `git diff <path>...`) and compares
> +	against the "base" version, "our branch" or "their
> +	branch" respectively.  With these options, diffs for
> +	merged entries are not shown.
> ++
> +The default is to diff against our branch (-2) and the
> +cleanly resolved paths.  The option -0 can be given to
> +omit diff output for unmerged entries and just show "Unmerged".

I am not sure what this comment about the default means.  Isn't the
default to use --cc?

> +
> +-c::
> +--cc::
> +	Produce "combined diff" (and "dense combined diff" showing how the
> +	result is different compared to more than one original.

Missing an article after "Produce" (produce a combined diff) and a
closing parenthesis after "dense combined diff", I think.

More importantly, it might be nice to say

	See the section "diff format for merges" of
	linkgit:git-diff[1] for details.

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

[Junio C Hamano]

Jonathan Nieder <jrnieder@gmail.com> writes:

>> --- a/Documentation/diff-options.txt
>> +++ b/Documentation/diff-options.txt
>> @@ -24,6 +24,37 @@ ifndef::git-format-patch[]
>>  --patch::
>>  	Generate patch (see section on generating patches).
>>  	{git-diff? This is the default.}
>> +
>> +-1 --base::
>> +-2 --ours::
>> +-3 --theirs::
>> +-0::
>> +	These make sense only when comparing the index and the working
>> +	tree (i.e. `git diff-files` or `git diff <path>...`) and compares
>> +	against the "base" version, "our branch" or "their
>> +	branch" respectively.  With these options, diffs for
>> +	merged entries are not shown.
>> ++
>> +The default is to diff against our branch (-2) and the
>> +cleanly resolved paths.  The option -0 can be given to
>> +omit diff output for unmerged entries and just show "Unmerged".
>
> I am not sure what this comment about the default means.  Isn't the
> default to use --cc?

Depends on where this is included.  That passage originally came from
diff-files, for which "-2 if exists otherwise -0" has been the default.
When included in "diff" (and perhaps "show"), --cc is used by default.
So we would need the "ifdef::git-diff-files[]/endif::git-diff-files[]"
around it.

>> +
>> +-c::
>> +--cc::
>> +	Produce "combined diff" (and "dense combined diff" showing how the
>> +	result is different compared to more than one original.

Similarly, we would need "ifdef::defaults-to-cc[]/endif" around a sentence
here to say that this is the default when showing unmerged entry.

> Missing an article after "Produce" (produce a combined diff) and a
> closing parenthesis after "dense combined diff", I think.
>
> More importantly, it might be nice to say
>
> 	See the section "diff format for merges" of
> 	linkgit:git-diff[1] for details.

Thanks.

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

[Piotr Krukowiecki]

On Mon, Mar 21, 2011 at 7:12 PM, Piotr Krukowiecki
<piotr.krukowiecki@gmail.com> wrote:
> W dniu 21.03.2011 17:41, Johannes Sixt pisze:
>> 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.

You were right - the line I've added manually have two "++", and the other
lines shown with differences only have "-" and "+" in the second column.

I'm still not clear what is exactly compared when I use plain diff or
-c version.
It might be I need to read more docs. I'll ask if I'm still in doubt
after reading
more.

Thanks again for explaining this to me - saved me from a lot of PITA researching
:)


-- 
Piotr Krukowiecki