Dangerous "git am --abort" behavior

I just noticed this, and I wonder if it has bitten me before without me noticing: "git am --abort" can be really dangerous.

What happened today was that I had been doing a pull or two, and then applied an emailed patch with "git am" as usual. But as sometimes happens, I actually had a previous "git am" that had failed - in fact, it was the same patch that I applied today that had had an earlier version that no longer applied.

So I just did "git am --abort" to get rid of the old stale 'am' state, but that actually also ended up aborting my "git pull". Oops.

Happily, I noticed, and did a "git reset --hard @{1}" to get things back, but at no point did "git am" warn about the implicit "reset" it did, that threw away non-am state.

I suspect I've avoided this in the past because my normal approach to getting rid of stale am state tends to be just the manual "rm -rf .git/rebase-apply", but it's also possible that I've simply not noticed before.

Maybe "git am" should actually save the last commit ID that it did, and only do the "reset" if the current HEAD matches the rebase-apply state and warns if it doesn't? Or maybe we could just introduce a new "git am --clean" that just flushes any old pending state (ie does that "clean_abort" thing, which is basically just the "rm -rf" I've done by hand). Or both?

Comments?

                     Linus