On Mon, May 25, 2009 at 12:02 PM, Jeff King <peff@xxxxxxxx> wrote: > On Mon, May 25, 2009 at 02:17:48PM +0200, Johannes Sixt wrote: > >> I wonder why we have this problem (and do something about it) with git-am, >> but not with git-rebase. Is it perhaps that the usual case were people >> were bitten by the old behavior is: > > I don't know. I had assumed a safety valve we put in git-am might need > to be matched in rebase. But I don't recall whether I have screwed > myself in the same way with rebase. Perhaps because rebase happens on a > detached HEAD, I tend to notice sooner that something is not right. Ah, maybe that's the difference. rebase seems to detach the HEAD, then do a bunch of stuff, then reset the original branch only when it's done. So aborting doesn't reset any branches at all, it just checks out the original branch. Thus one option would be to try to make am more like rebase: detach the HEAD before it starts, and reattach it only on success. At least then you only have one set of UI problems to fix. (Of course, I've gotten myself into trouble anyway by checking new stuff in on the detached HEAD and later aborting a rebase. I have quite a love-hate relationship with detached HEADs.) Maybe the best solution here isn't to prevent people from shooting themselves in the foot, but instead to help them recover afterwards. I've noticed most people don't know about 'git reflog'; they often seem astonished when I tell them about it. reflog + not blowing away dirty repositories would mean that you're always safe. Have fun, Avery -- 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