Re: Possible d/f conflict bug or regression

[Junio C Hamano <gitster@pobox.com>]

Christian Couder <chriscool@tuxfamily.org> writes:

> 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 haven't had time to fully clean-up the patch series, but I have a fix
for this (and a bit broader set of cases).  "git add -u" shares the same
issue as the "git commit -a" at the last step in your sequence.

"commit -a" and "add -u" are about "check the index and work tree to
see if anything that is in the index is changed in the work tree, and
update the entry (either remove or add)".  When we are looking at an
existing index entry "foo", possible cases include:

 - it has not been changed (=> do nothing);
 - it is not there anymore (=> do "git update-index --add --remove foo")
 - its contents or executableness changed (ditto);
 - its type changed (e.g. reg-to-symlink) (ditto);

If you did "rm foo; mkdir foo", then that is "it is not there anymore"
case.

If you did "rm foo; mkdir foo; (cd foo && git init)", and worked in this
new foo/ repository to cause its HEAD to point at a commit, then that is
"its type changed to a gitlink" case (iow, you added a submodule).

The above two cases are not handled properly; the breakage is in
diff-files but non-cached diff-index shares the same issue.  The root
cause is not Kristian's "rewrite commit in C", but is much more older
"gitlink to support submodules" series, that started at f35a6d3 (Teach
core object handling functions about gitlinks, 2007-04-09).

Will send the patches out tonight but I have to tend some other chores
first.