Directory replaced with a file confuses cherry-pick

Hello!

I think I've found a bug. Here is how to reproduce.

1. Create an empty repo.
2. Add the following: file.txt containing "before" and directory problem/  
with file problem/content containing "data". Commit this.
3. From here, create a branch and commit a change to file.txt: change it  
to say "after".
4. Checkout master.
5. Remove directory problem/ and add a file with the same name (problem)  
containing "newdata". Commit this.
6. Try to cherry-pick the commit you made on the side branch on step 3.

Here is what you see:

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 64f21a85fa3deb4d3952b0471f442a76e5147b05

And git-status says:

# On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: file.txt # # Unmerged paths: # (use "git reset HEAD <file>..." to unstage) # (use "git add/rm <file>..." as appropriate to mark resolution) # # added by us: problem # # Untracked files: # (use "git add <file>..." to include in what will be committed) # # problem~HEAD

Expected result: the cherry-pick goes smoothly. The change I'm cherry-picking (modification of file.txt) has nothing to do with the problem file/directory. Trying to cherry-pick anything from branches that stem off from before the change of a directory to a file fails like this.

Known? Is replacing directories with files maybe a taboo?

On Friday 18 February 2011, Alexey Feldgendler wrote:

Unable to reproduce. Here are the commands I used (please post yours):

$ git init
$ echo before > file.txt
$ mkdir problem
$ echo data > problem/content
$ git add .
$ git commit -m first
$ git checkout -b side
$ echo after > file.txt 
$ git commit -a -m side-commit
$ git checkout master
$ git rm -r problem # or: rm -rf problem
$ echo newdata > problem
$ git add problem # this is important!
$ git commit -m second
$ git cherry-pick side
[master b975587] side-commit
 1 files changed, 1 insertions(+), 1 deletions(-)

No conflict in the cherry-pick.

I cannot easily see how you got into this state. Maybe you forgot to 'git add' the "problem" file before making the second commit?

Agreed. And that's exactly what I'm seeing above.

This should not be the case. Which Git version are you using?

Nope. dir->file replacements should not be problematic.

...Johan

On Fri, 18 Feb 2011 15:44:05 +0100, Johan Herland <johan@herland.net> wrote:

I tried your exact script now, line by line, and it failed in the way I described.

git is from Debian testing, package version 1:1.7.2.3-2.2.

(please don't cull the CC list when replying)

On Friday 18 February 2011, Alexey Feldgendler wrote:

I'm going away for the weekend, so I can't investigate this right now. Could you please retry with a more recent Git? Maybe someone else already knows which patch might have fixed this issue?

Have fun! :)

...Johan

On 18/02/11 14:06, Alexey Feldgendler wrote:

It looks like one I found in 1.7.0.4 - for which Elijah Newren submitted some patches, although I don't happen to know what their current status is.

  http://comments.gmane.org/gmane.comp.version-control.git/155147

N

Nick <oinksocket@letterboxes.org> writes:

Isn't v1.7.4-rc0~101 a polished version of that one?