[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,

-- 
Matthieu