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

From: Johannes Sixt <j.sixt@viscovery.net>
Date: May 25, 2009, 12:17 UTC
Message-ID: <4A1A8C6C.5020009@viscovery.net>
In-Reply-To: <20090525120019.GA1740@coredump.intra.peff.net>

Jeff King schrieb:

Show 22 quoted lines

> On Mon, May 25, 2009 at 01:49:18PM +0200, Johannes Schindelin wrote:
> 
>>> 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.

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:

   $ git am mbox
   .... stops with conflicts
   .... oops, wrong branch
   $ git checkout other-branch
   $ git am mbox
   error: git am is already in progress
   $ git am --abort
   OUTCH! other-branch was reset!

rebase is not used in this manner, and even though it does reset --hard, it doesn't hurt (that often).

-- Hannes