Jeff King schrieb: > 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 -- 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