Re: git commit -a reports untracked files after a clone

From: Jeff King <peff@peff.net>
Date: May 16, 2011, 14:55 UTC
Message-ID: <20110516145535.GA25930@sigill.intra.peff.net>
In-Reply-To: <1D7CF554-A4AC-49EF-A095-9B05167BC458@goli.at>

On Mon, May 16, 2011 at 02:38:33PM +0200, Philipp Metzler wrote:

> Could be a race condition / heisenbug yep. The result of "git commit
> -a" differs - the directories vcs-svn and xdiff are there all the time
> but not the others. The only constant thing is that the command "git
> status" always "cleans up" everything. Another run:

OK, I'm making some progress. I can replicate on Linux with:

  $ git config core.ignorecase true
  $ git clone git foo
  $ cd foo && git commit -a

which gives a bunch of directories which contain tracked contents. Doing "git status" makes the problem go away, but then doing this makes it come back:

  $ rm .git/index
  $ git read-tree --reset HEAD

And like you, it doesn't trigger with "-uall".

So it is something about:

  1. A fresh index that is perhaps missing stat information for some
     entries.

  2. Stopping the traversal at the directory boundary rather than
     looking at details of each directory ("-uall").

  3. core.ignorecase

But it is definitely repeatable. Which is good, because that will make it easier to track down. :)

I'll see what I can do, but it may not be today.

-Peff