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