Checkout fails when one branch contains a directory with the name of a file in the other branch

Hi,

I am not sure whether this is intentional or not. I am wondering why this scenario fails, and if it is by design, how I should handle this situation:

-------------------------------------------------------------------------------- $ mkdir test

$ cd test

$ git init Initialized empty Git repository in .git/

$ echo aFile > aFile

$ git add aFile

$ git commit -m "initial"
Created initial commit a4aa48bb4ca57699341e380b17a1c3d92e44d08b
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 aFile

$ git checkout -b branch Switched to a new branch "branch"

$ git rm aFile rm 'aFile'

$ git commit -m "No aFile file anymore"

Created commit 6ac689ae4d7e8c0d82526d84563c12109b6cd900
 1 files changed, 0 insertions(+), 1 deletions(-)
 delete mode 100644 jacob

$ mkdir aFile

$ touch aFile/anotherFile

$ git add aFile/anotherFile 

$ git commit -m "added aFile directory"
Created commit 634e5fff2fdb6365d4be5b2dca29e9c78164cb07
 0 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 aFile/anotherFile

$ git checkout master fatal: Untracked working tree file 'aFile' would be overwritten by merge. --------------------------------------------------------------------------------

Regards, Tom Koelman

Hi,

On Mon, 7 May 2007, Tom Koelman wrote:

I tried to reproduce this behaviour, but it worked here. What Git version do you use? Mine says "git version 1.5.2.rc2.2435.ge5a9b".

Hth, Dscho

Johannes Schindelin wrote:

I tried 1.5.1.3 under cygwin and 1.5.0.6 under Linux FC5.

Regards, Tom Koelman

Hi,

On Mon, 7 May 2007, Tom Koelman wrote:

I can confirm that it reproduces with 1.5.1.3. So, it has been fixed in 1.5.2.rc2.

Ciao, Dscho