[FAQ?] Rationale for git's way to manage the index

Hi,

I've read the manual, and I belive I have a correct understanding of how the index works, technically speaking. Still, I'm not clear about the rational for such design.

Almost any other decent system has an equivalent to cache the stat information (bzr calls this stat-cache, hg calls it dirstate IIRC). That is, if your run "$vcs diff" twice, the second run will only need to stat all files, never diff them.

But the fact that git actually remembers the _content_ of files in the index, and that the default behavior for "commit" is to commit only the content that is explicitely "git add"ed is something I've never seen outside git.

At first, I find it rather annoying. My usual workflow is

<hack hack hack> % $vcs status % $vcs commit -m "describe whatever I did" <hack hack hack> ...

With git, i'd do

<hack hack hack> % git status % git add X % git add Y % git status % git commit

or

<hack hack hack> % git satus -a % git commit -a -m "..."

In the former case, I have more commands to type, and in the second case, I loose part of the stat-cache benefit: If I run "git status -a" twice, the second run will actually diff all the files touched since the last run, since "git status -a" actually updated a temporary index, and discarded it afterwards, so it doesn't update the stat information in the index (while "git status" would have).

In both cases, I can't really see the benefit. I'm pretty sure this is a FAQ, and I'm also pretty sure there are good arguments for it, but I can't find it anywhere.

Thanks for your answers,