From: Junio C Hamano Date: Fri, 08 May 2009 09:01:16 GMT Subject: Re: Bug: 'git am --abort' can silently reset the wrong branch Message-ID: <7v7i0s0y03.fsf@alter.siamese.dyndns.org> In-Reply-To: <20090508082826.GA29737@coredump.intra.peff.net> Jeff King writes: > Switching branches and clobbering some other branch > with --abort is just _one_ thing you can do to screw yourself. You could > also have been doing useful work on the _same_ branch, and that would > get clobbered by --abort. However, I'm not sure if we have a good way > of telling the difference between "work which I did to try to get these > patches to apply, but which should be thrown away when I abort" and > "work which I did because I forgot I had an active git-am". I think I've said this already, but honestly speaking, I think --abort should not do --reset at all, but just remove the $dotest directory. Or perhaps introduce a --clear option to do so. At least your patch is an improvement. What I sometimes see to my users happen is to try applying to the oldest integration branch the patch (the users think) ought to apply, see it fail to apply, switch to a bit newer branch and run "am" again (trusting that it will pick up the material from $dotest), repeat the above and then give up with "git am --abort". I do not think anybody can offhand explain to which branch and to what state the command takes the user back to in such a situation without looking at what the code actually does X-<; even though I think it should take the user back to the original branch, I do not think that is what the code does.