"git am --abort" screwing up index?

So I just noticed while applying a patch with "git am" when I had a dirty tree, and I ended up getting a failure and starting over:

   [torvalds@i7 linux]$ git am --abort
   [torvalds@i7 linux]$ git reset --hard
   Checking out files: 100% (50794/50794), done.0794)
   HEAD is now at 1efdb5f0a924 Merge tag 'scsi-fixes' of
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi

and the thing I reacted to is that the "git reset --hard" re-checked out all the files.

That implies that "git am --abort" ended up leaving the index in a bad state, presumably it re-did the index entirely from HEAD, without filling it in with the stat() details from the old index.

Maybe it has always done this, and I just haven't noticed (I usually _just_ do the "git reset --hard" thing, don't ask me why I wanted to be doubly sure this time). But maybe it's an effect of the new built-in "am".

I'm about to go out and don't have time to debug this any further right now, but I'll try to get back to it later. I thought I'd send out this email in case it makes Paul goes "ahh, yes.. obvious"

Not a big deal - things *work* fine. But forcing checking out every file obviously also means that subsequent builds end up being slowed down etc.,.

                  Linus