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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html