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

2010/1/5 Sam Vilain [off-list ref]:

On Tue, 2010-01-05 at 12:33 +0000, Hakim Cassimally wrote:

quoted

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.

 [...]

quoted

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.

 [...]

quoted

    (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.

quoted

    (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