Christian Couder <chriscool@xxxxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
