Re: [RFC PATCH] am: do not do any reset on --abort

From: Jeff King <peff@peff.net>
Date: May 25, 2009, 12:00 UTC
Message-ID: <20090525120019.GA1740@coredump.intra.peff.net>
In-Reply-To: <alpine.DEB.1.00.0905251348050.4288@intel-tinevez-2-302>

On Mon, May 25, 2009 at 01:49:18PM +0200, Johannes Schindelin wrote:

Show 11 quoted lines

> > We really have no idea what state the tree is in at this
> > point, and whether the user might have done useful work on
> > top of it. So let's err on the side of keeping the user's
> > data intact.
> > 
> > The downside is that if they do have cruft to get rid of, or
> > want to pretend as if earlier parts of the series that were
> > applied did not exist, they must manually "git reset --hard"
> > now.
> 
> Hmm.  I think I would revert that patch after merging git.git right away.

You know, you can just say you don't like it. ;)

> Can you at least check for a dirty tree and reset --hard if it is clean?

No, that would defeat the purpose. The problem is that we have no idea what has happened since the initial "git am". The user may have made commits they want to keep, and we don't want to reset those away. They may even have pulled, which means ORIG_HEAD can no longer be trusted for a reset.

> In the other case, you could still say "you seem to have modifications, 
> bla bla bla"...

I think you raise a good point here. If we do decide to stop doing the reset automatically, it is probably better not to simply stop doing it (as my patch does), but to downgrade it to a warning ("You probably want to reset, etc...").

-Peff