Re: Possible d/f conflict bug or regression

From: Bryan Donlan <bdonlan@gmail.com>
Date: Mar 30, 2008, 01:29 UTC
Message-ID: <3e8340490803291829h6f9c39a5uf4a1b2a4e52103ca@mail.gmail.com>
In-Reply-To: <200803290813.08419.chriscool@tuxfamily.org>

On Sat, Mar 29, 2008 at 3:13 AM, Christian Couder <chriscool@tuxfamily.org> wrote:

Show 23 quoted lines

> Hi,
>
>  When doing something like:
>
>  mkdir testdir &&
>         cd testdir &&
>         touch foo &&
>         git init &&
>         git add . &&
>         git commit -m 'Initial commit.' &&
>         rm foo &&
>         mkdir foo &&
>         git commit -a -m 'Test.'
>
>  I get:
>
>  Initialized empty Git repository in .git/
>  Created initial commit 3f945ca: Initial commit.
>   0 files changed, 0 insertions(+), 0 deletions(-)
>   create mode 100644 foo
>  fatal: unable to index file foo
>
>  I think it's quite bad that it doesn't work.

What behavior would you expect this to have? IMO, it's not entirely clear what the user means to do if they replace a file with an empty directory, as an empty directory cannot be added to the index. Even with a directory with contents, some of the contents may be junk (.o for example) as far as the user is concerned.

Would a clearer diagnostic be a good solution? Something like: fatal: foo: file replaced by directory. Use git rm --cached or git add to specify how this should be handled.

Thanks,

Bryan