Re: Bug: 'git am --abort' can silently reset the wrong branch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jeff King <peff@xxxxxxxx> 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.

--
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]