Merging a commit from a distant branch, cherry-pick seems to fail

Hi list,

I'm one of the lead developers for KMess. Recently, I've been doing some work regarding KMess on Mac, in a branch called 'noknotify' (because knotify works like shit on Mac). This branch was branched off of the master branch a few days ago. The master branch has had major development activity in the last half year, as the KMess version that will eventually be 2.1 or so. Before that, we released a kmess-2.0.x branch; this branch has been relatively silent since branching off from master.

Now, after those changes in noknotify, I want to merge them back into kmess-2.0.x. However, the two branches noknotify and kmess-2.0.x are hugely apart. The changes in the commit I want to merge are to files which haven't changed a lot (apart from the ChangeLog and CMakeLists.txt) and should apply somewhat cleanly.

So I switched branches, made sure my branch was clean, made sure I was taking the right commit, and cherry-picked the interesting commit from the other branch.

<<<<<<
sjors@smbp:~/Projecten/kmess/git$ git checkout kmess-2.0.x
Switched to branch 'kmess-2.0.x'
sjors@smbp:~/Projecten/kmess/git$ git status
# On branch kmess-2.0.x
nothing to commit (working directory clean)
sjors@smbp:~/Projecten/kmess/git$ git log -1 --name-only --oneline f9380fd43a2c1
f9380fd 2010-06-03 (Sjors) (noknotify branch)
ChangeLog
src/CMakeLists.txt
src/notification/macnotification.cpp
src/notification/macnotification.h
src/notification/notificationmanager.cpp
src/notification/notificationmanager.h
sjors@smbp:~/Projecten/kmess/git$ git cherry-pick -n f9380fd43a2c1cb75d97c7a667d652195e674824
Automatic cherry-pick failed.  After resolving the conflicts,
mark the corrected paths with 'git add <paths>' or 'git rm <paths>'
and commit the result with: 

        git commit -c f9380fd43a2c1cb75d97c7a667d652195e674824
<<<<<<<

Apparantly, this failed. The reason why: Instead of changing just those few files in the commit, git was apparantly trying to merge a lot more, see:

<<<<<<<
sjors@smbp:~/Projecten/kmess/git$ git status
# On branch kmess-2.0.x
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#	modified:   src/CMakeLists.txt
#	new file:   src/notification/macnotification.cpp
#	new file:   src/notification/macnotification.h
#	modified:   src/notification/notificationmanager.cpp
#
# Unmerged paths:
#   (use "git reset HEAD <file>..." to unstage)
#   (use "git add/rm <file>..." as appropriate to mark resolution)
#
#	both modified:      ChangeLog
#	added by us:        contrib/isf-qt
#	both modified:      src/notification/notificationmanager.h
#
sjors@smbp:~/Projecten/kmess/git$ git diff ChangeLog | head -n 20
diff --cc ChangeLog
index ef7223f,ca14ce8..0000000

--- a/ChangeLog
+++ b/ChangeLog

@@@ -1,134 -1,101 +1,148 @@@
++<<<<<<< HEAD
 +2010-05-31 (Adam)
 + * Fix bug in chatwindow.ui: use the global include for IsfInkCanvas.
++=======
+ 
+ 2010-06-03 (Sjors) (noknotify branch)
+  * Added MacNotification class, which currently makes the KMess icon in the
+    Dock 'jump' when its method is called.
+  * Made the NotificationManager use MacNotification instead when doing
+    notifications on the Mac.
+ 
+ 2010-05-29 (Adam)
+  * Update the use of the MsnSession API (no more "get" prefix).
+  * Disable meeting/invite/send file buttons if chatting to a Yahoo! contact
+  * Handle YahooMessage in Chat
<<<<<<<<

The lines added starting with "2010-05-29 (Adam)" are not from kmess-2.0.x, but from 'master' - the lines are also present in the snapshot of noknotify after commit f9380fd43, but weren't changed in that commit.

I'd have expected git cherry-pick to simply take the changes in commit f9380fd43 and apply them to kmess-2.0.x, without pulling along history in 'master'. Testing and debugging in the #git channel on Freenode didn't show what I was doing wrong (<http://git.pastebin.com/dUntbHDV>). Now I could just take the patch with 'git show' and use 'git apply' to apply it, but that doesn't seem like the Git way to do this. So the question is: does any of you know why this is happening, what I'm doing wrong, and what I should do instead?

BTW: my repository is a synchronised clone of http://gitorious.org/kmess/kmess, so you can all try stuff yourself :)

Thank you,
Sjors

Am 6/8/2010 0:46, schrieb Sjors Gielen:

sjors@smbp:~/Projecten/kmess/git$ git log -1 --name-only --oneline f9380fd43a2c1
f9380fd 2010-06-03 (Sjors) (noknotify branch)
ChangeLog
src/CMakeLists.txt
src/notification/macnotification.cpp
src/notification/macnotification.h
src/notification/notificationmanager.cpp
src/notification/notificationmanager.h

...

sjors@smbp:~/Projecten/kmess/git$ git status
# On branch kmess-2.0.x
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#	modified:   src/CMakeLists.txt
#	new file:   src/notification/macnotification.cpp
#	new file:   src/notification/macnotification.h
#	modified:   src/notification/notificationmanager.cpp
#
# Unmerged paths:
#   (use "git reset HEAD <file>..." to unstage)
#   (use "git add/rm <file>..." as appropriate to mark resolution)
#
#	both modified:      ChangeLog
#	added by us:        contrib/isf-qt
#	both modified:      src/notification/notificationmanager.h
#

...

I'd have expected git cherry-pick to simply take the changes in commit
f9380fd43 and apply them to kmess-2.0.x, without pulling along history
in 'master'. Testing and debugging in the #git channel on Freenode didn't
show what I was doing wrong (<http://git.pastebin.com/dUntbHDV>). Now I
could just take the patch with 'git show' and use 'git apply' to apply it,
but that doesn't seem like the Git way to do this. So the question is:
does any of you know why this is happening, what I'm doing wrong, and what
I should do instead?

You did nothing wrong. If at all, there is a bug in git.

The *only* curious thing after your cherry-pick is this:

#	added by us:        contrib/isf-qt

because contrib/isf-qt is not touched by the commit that you are
cherry-picking.

contrib/isf-qt is a submodule on branch kmess-2.0.x, but it is a regular
directory on master. I don't think that git should report it as a conflict.

To go ahead, simply resolve the conflicts in ChangeLog and
notificationmanager.h, and make sure that you do not have staged any
changes to contrib/isf-qt before you commit.

-- Hannes

From: Johannes Sixt <redacted>

When one side of a merge turns a directory into a submodule, and the other
side does not touch that directory (but has other non-conflicting changes),
then a merge should succeed. But currently, it does not; it rather fails
with a file/directory conflict.

Signed-off-by: Johannes Sixt <redacted>
---
Am 6/8/2010 7:57, schrieb Johannes Sixt:

The *only* curious thing after your cherry-pick is this:

quoted

#	added by us:        contrib/isf-qt

because contrib/isf-qt is not touched by the commit that you are
cherry-picking.

Here's a test case that exhibits the bug in merge-recursive;
at least, I think it is a bug.

-- Hannes

 t/t3030-merge-recursive.sh |   29 +++++++++++++++++++++++++++++
 1 files changed, 29 insertions(+), 0 deletions(-)

diff --git a/t/t3030-merge-recursive.sh b/t/t3030-merge-recursive.sh
index 9929f82..9eae6e9 100755
--- a/t/t3030-merge-recursive.sh
+++ b/t/t3030-merge-recursive.sh

@@ -22,6 +22,7 @@ test_expect_success 'setup 1' '
 	git branch df-2 &&
 	git branch df-3 &&
 	git branch remove &&
+	git branch submod &&
 
 	echo hello >>a &&
 	cp a d/e &&

@@ -236,6 +237,17 @@ test_expect_success 'setup 6' '
 	test_cmp expected actual
 '
 
+test_expect_success 'setup 7' '
+
+	git checkout submod &&
+	git rm d/e &&
+	test_tick &&
+	git commit -m "remove d/e" &&
+	git update-index --add --cacheinfo 160000 $c1 d &&
+	test_tick &&
+	git commit -m "make d/ a submodule"
+'
+
 test_expect_success 'merge-recursive simple' '
 
 	rm -fr [abcd] &&

@@ -551,4 +563,21 @@ test_expect_success 'merge removes empty directories' '
 	test_must_fail test -d d
 '
 
+test_expect_failure 'merge-recursive simple w/submodule' '
+
+	git checkout submod &&
+	git merge remove
+'
+
+test_expect_failure 'merge-recursive simple w/submodule result' '
+
+	git ls-files -s >actual &&
+	(
+		echo "100644 $o5 0	a"
+		echo "100644 $o0 0	c"
+		echo "100644 $c1 0	d"
+	) >expected &&
+	test_cmp expected actual
+'
+
 test_done

-- 
1.7.1.75.g68e2c

Am 6/8/2010 13:34, schrieb Johannes Sixt:

+test_expect_failure 'merge-recursive simple w/submodule result' '
+
+	git ls-files -s >actual &&
+	(
+		echo "100644 $o5 0	a"
+		echo "100644 $o0 0	c"
+		echo "100644 $c1 0	d"

Make this line
		echo "160000 $c1 0	d"
Sorry!

+	) >expected &&
+	test_cmp expected actual

-- Hannes