Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > 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. I never got into this as I use bash completion in my PS1 in the real life, but I've seen this happen while playing around, and I can see myself easily getting hurt by this behaviour without status in PS1. > 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? I sometimes wanted "--clean" myself, so it is a no-brainer to decide that it would be a good thing to add. The last time I thought about this issue, I wasn't sure about "compare with the last commit"---mostly because it wasn't clear what ramifications it would have. When you get refusal from "am --abort", how would you recover from it? Back then my tentative conclusion was actually to get rid of "am --abort" and give "am --clean", making the final "reset HEAD~$n" the responsiblity of the user. But I forgot to pursue it. -- 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