Hakim Cassimally <hakim.cassimally@xxxxxxxxx> writes:
>>> (stable) $ git cherry-pick 301afce1
>>> Finished one cherry-pick.
>>> www/client/css/admin.css: needs merge
>>> <...snip>
>>> www/client/css/admin.css: unmerged (8e7cd850bf40d1a921b1f62ce0945abd374fa55d)
>>> <...snip>
>>> ...
>>> error: Error building trees
>>
> $ git ls-files -s -u www/client/css/admin.css # only staged/unmerged
> 100755 8e7cd850bf40d1a921b1f62ce0945abd374fa55d 2
> www/client/css/admin.css
>
> (i.e. when run after the failed cherry-pick)
>
>> Also take the 'git ls-tree -r HEAD', 'git ls-tree -r 301afce1' and 'git
>> ls-tree -r 301afce1^' output, and grep for the files in question. The
>> answer (or at least a bug triage) should be in the output of those
>> commands.
>
> $ git ls-tree HEAD | grep www/client/css/admin.css
> 100755 blob 8e7cd850bf40d1a921b1f62ce0945abd374fa55d
> www/client/css/admin.css
>
> There's no entry in git ls-tree 301afce1 or 301afce1^1 though. I'd
> guess that's significant, but I don't know what answer it suggests...
>
> (However the file exists in both (stable) and (experimental)...
> and is identical in both).
> ....
So in short:
* commit 301a added a new path bin/upload_module.pl;
* the state you cherry-picked this commit to was clean (i.e. before
running cherry-pick, "git status" reported no local changes to the
index nor to the work tree);
* the commit, the index, and the work tree before running this
cherry-pick had www/client/css/admin.css file, which also existed in
301a and 301a^, but all of these three commits had the same contents.
A simple minded attempt to reproduce this (attached below) by preparing a
commit that adds one new file and attempting to transplant to an unrelated
commit that doesn't have the file didn't work; I have been scratching my
head.
What "cherry-pick" internally does is to run:
git merge-recursive 301a^ -- HEAD 301a
That is, "We are at HEAD; consolidate the change since 301a^ to 301a into
our state, and leave the result in the index and the work tree". Then it
commits the result. One thing to try is to see if this gives the same
kind of breakage.
The only other thing that _may_ be involved is if there are paths that
turned between directories and files on the two histories, or perhaps
there are paths like "www-frotz", "www.frotz", etc (i.e. "www" followed by
a byte whose ASCII value comes before '/') involved, and unpack_trees()
machinery the merge-recursive internally uses are getting confused about
D/F conflicts. To diagnose it, it would be helpful to get the full output
from these two commands:
git ls-tree -r -t HEAD (before cherry-pick)
git ls-tree -r -t 301a (the commit you are transplanting)
Thanks
---
diff --git a/t/t3506-cherry-pick-addremove.sh b/t/t3506-cherry-pick-addremove.sh
new file mode 100755
index 0000000..e7dcd77
--- /dev/null
+++ b/t/t3506-cherry-pick-addremove.sh
@@ -0,0 +1,26 @@
+#!/bin/sh
+
+test_description='unrelated files added by our side'
+
+. ./test-lib.sh
+
+test_expect_success setup '
+ test_commit A &&
+ git branch side &&
+ test_commit B &&
+ test_commit C &&
+
+ git checkout side &&
+ test_commit D &&
+ test_commit E &&
+
+ git checkout master
+'
+
+test_expect_success 'cherry-pick' '
+ git reset --hard C &&
+ git cherry-pick side &&
+ git grep E E.t
+'
+
+test_done
--
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