> From: gitster@xxxxxxxxx
> Date: Sat, 28 May 2011 11:51:32 -0700
>
> Martin von Zweigbergk writes:
>
> > ... I think Junio then
> > hinted that he sometimes wished that he could abort rebase without
> > moving to anywhere else at all, which is what this patch implements.
>
> I am not opposed to this particular patch, but thinking about a bigger
> picture, I am not sure if we want to solve it this way.
>
> We have multiple "sequence" operations that want to do things in multiple
> steps, each of which can stop and give control back to the user, while
> leaving some information in the .git directory for it to know where it was
> when resuming. I think "am" knows about what "rebase" does (and
> vice-versa) so it can detect an attempt to run it while "rebase" is in
> still progress and refuse to continue to limit the damage, but if we have
> N such "sequence" commands that want to refrain from interfering with each
> other, and want to offer an advice to abort the in-progress operation
> initiated by other commands, that would mean we would need N * N pieces of
> logic to detect other's in-limbo state and offer advices, which would not
> scale.
>
> A user who is given back the control from a "sequence" operation may be
> confused either (1) immediately after such an event (often some sort of
> merge conflict) or (2) much later after first abandoning the working tree
> altogether and taking a walk and then coming back to continue working
> while forgetting what he was doing. Such a user may want to say "I know I
> am in a strange state, give me a state that I can work from, at this point
> I do not care about continuing what I was originally doing". The user may
> probably not know if "git rebase" was in progress or "git cherry-pick"
> was.
>
> "git reset --hard" used to be such a command in simpler times. It removes
> MERGE_HEAD unconditionally, so that a confused user can start from scratch
> without having to worry about what was in progress. As a devil's advocate,
> I am wondering if it is a good idea to simply teach "reset --hard" to also
> remove any and all "sequence" cruft (.git/rebase-apply, .git/rebase-merge,
> CHERRY_PICK_HEAD; we might have others I do not recall offhand) and be
> done with it. It is a large hammer, but it is certainly the easiest to
> explain and the simplest to understand way to get out of any troubles.
I'd just like to say that I sometime use "git reset --hard" in the middle
of a "git rebase" when I want to get rid of some changes completely.
Now, I'm not saying that this is the best way of doing it ("git checkout --"
is probably far superior?), but I daresay that there are some users out
there who will be surprised by the new behaviour of "git reset --hard".
Having said that, before I knew that "git reset --hard" could be used
in the middle of a rebase without aborting the reset, I did try to use it
to abort the rebase, because, as you said, it seems to be "uh oh" button
in git.
So it's a bit of a toss-up really.
Having said that, I would support making "reset --hard" abort rebases,
on the condition that there are some _big_ warnings somewhere about
the change in behaviour.
Tim.
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
--
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