cherry-picking a commit clobbers a file which is a directory in the target commit

[Nick <oinksocket@letterboxes.org>]

This was seen on git version 1.7.0.4 on Ubuntu Lucid.

Basically, cherry-picking a commit from a branch where a file in the current
branch has been replaced by a directory, git clobbers the file and the
cherry-pick fails reporting conflicts.

To replicate:

   $ mkdir clobber
   $ cd clobber/
   $ git init
   $ touch sausage
   $ git add sausage
   $ git commit -m "added sausage"
   $ git checkout -b branch1
   $ mv sausage sausage1
   $ mkdir sausage
   $ mv sausage1 sausage/roll
   $ git add sausage/roll
   $ git commit -m "renamed sausage as sausage/roll"
   $ touch falafel
   $ git add falafel
   $ git commit -m "added falafel"
   $ git checkout master

Now if you try to cherry pick the commit just added to branch1 onto master:

    $ git cherry-pick branch1
    Automatic cherry-pick failed.  After resolving the conflicts,
    mark the corrected paths with 'git add <paths>' or 'git rm <paths>'
    and commit the result with:

            git commit -c branch1

    $ git status
    # On branch master
    # Changes to be committed:
    #   (use "git reset HEAD <file>..." to unstage)
    #
    #       renamed:    sausage -> falafel
    #
    # Untracked files:
    #   (use "git add <file>..." to include in what will be committed)
    #
    #       sausage~HEAD

Not what I expected at all. I'd not expect the file 'sausage' to be modified,
just the new file 'falafel' added, as I did in the original commit.

I know I can recover from this by moving sausage~HEAD back to sausage, or delete
it and check out sausage again, but I suspect it just shouldn't happen at all.


Is this a bug?

N