Re: git-cherry-pick problem - directory not touched by commit is marked "added by us"
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jan 7, 2010, 03:30 UTC
- Message-ID
- <7v4omyfv6h.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <82cfa8031001060328r21aa8de3s5c2dd5dac005b679@mail.gmail.com>
Hakim Cassimally <hakim.cassimally@gmail.com> writes:
Show 30 quoted lines
>>> (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