git status reads too many files

After a git checkout, git status has a tendency to read all the files that were updated during the checkout. In git.git for example:

$ git checkout -b here v1.7.4 Switched to a new branch 'here' $ git checkout -b there v1.7.4.1 Switched to a new branch 'there' $ strace -o /tmp/trace1 git status # On branch there nothing to commit (working directory clean) $ grep ^open /tmp/trace1 | wc -l 414 $ git diff --name-only here..there | tail -1 wrapper.c $ grep -A2 wrapper.c /tmp/trace1 lstat("wrapper.c", {st_mode=S_IFREG|0644, st_size=7617, ...}) = 0 open("wrapper.c", O_RDONLY) = 3 read(3, "/*\n * Various trivial helper wra"..., 7617) = 7617 close(3) = 0 $

This persistent across multiple runs of git status:

$ strace -o /tmp/trace2 git status # On branch there nothing to commit (working directory clean) $ grep ^open /tmp/trace2 | wc -l 414 $

...until the index is touched:

$ touch .git/index $ strace -o /tmp/trace3 git status # On branch there nothing to commit (working directory clean) $ grep ^open /tmp/trace3 | wc -l 362 $

This happening at least with 1.7.0.4 and 1.7.4.1.343.ga91df (master as of now)...

Further scrutiny reveals that when this happens, the index and the newly updated files in the working tree have identical modification times, so I guess git status is reading all files which are not older than the index...

Discussing this with Mr. Schindelin last week, my first thought was that checkout should ensure that the index is newer than any of the files in the working tree but Johannes seems to think that instead, the first git status run should touch the index, thus preventing the next run from reading the files again.

I'm not familiar enough with the semantics of the index to say which way is correct or intended, but surely the current behaviour is not desirable.

Bug?