2010/1/5 Sam Vilain <sam@xxxxxxxxxx>: > On Tue, 2010-01-05 at 12:33 +0000, Hakim Cassimally wrote: >> I got into a bit of trouble with a git-cherry-pick last night, and >> though mugwump >> and others on #git helped me as far as a workaround, > Yes, that was me. I'm very confused by the bug, too. > > [...] >> WHAT HAPPENS >> ============ >> >> When I'm in (stable), and try to cherry-pick the change from (experimental), >> git thinks that I'm making a massive number of changes in a directory that >> wasn't touched by the relevant commit. > [...] >> (stable) $ git --version >> git version 1.6.6 >> # I tried previously on 1.6.0.4 but upgraded in case it helped >> >> (stable) $ git status >> # On branch stable >> # nothing to commit (working directory clean) >> >> (stable) $ git show --stat 301afce1 >> commit 301afce1c78380276d208077ef4ec76b469c1024 >> Author: osfameron <...> >> Date: Wed Dec 23 23:45:20 2009 +0000 >> >> Proof of concept for import module (parse Excel) >> >> bin/upload_module.pl | 142 >> ++++++++++++++++++++++++++++++++++++++++++++++++++ >> 1 files changed, 142 insertions(+), 0 deletions(-) >> >> (stable) $ git whatchanged -1 301afce1 >> commit 301afce1c78380276d208077ef4ec76b469c1024 >> Author: osfameron <...> >> Date: Wed Dec 23 23:45:20 2009 +0000 >> >> Proof of concept for import module (parse Excel) >> >> :000000 100644 0000000... c90e261... A bin/upload_module.pl > > So by here, we know that the commit only affects that single file. No > funny stuff like mode changes of other files. > >> (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 > > Then, wham, these files want to be changed. What is the diff-tree > inside revert/cherry-pick doing differently to the one in log? > Hakim, one more useful thing in this situation would be to show the > state of these files in the index; > > git ls-files -s -u $ 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). > You can reproduce exactly the merge by making a new branch at the > position where you were attempting to land the cherry pick before, and > checking that branch out. I actually did $ cd .. $ git clone repo/ repo_backup_4Jan beforehand, so this should also be an exact reproduction, I think? > One last test, would be to check that it happens on a clean clone of the > repository. I don't think that you're hitting any repository-local > behaviour (eg, the ability to mark certain files as "always ignore") but > you never know. These commands are all being run on the same working > copy, right? And see above, should be an entirely clean clone. Thanks for the suggestions! Hakim / osfameron -- 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