Re: git-cherry-pick problem - directory not touched by commit is marked "added by us"

[Hakim Cassimally <hakim.cassimally@gmail.com>]

2010/1/5 Sam Vilain <sam@vilain.net>:
> 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