Re: [RFD] make rebase abort to original branch, not rebased branch

From: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Date: Mar 13, 2011, 14:58 UTC
Message-ID: <alpine.DEB.2.00.1103131013370.15442@debian>
In-Reply-To: <7vmxkzijpt.fsf@alter.siamese.dyndns.org>

On Sat, 12 Mar 2011, Junio C Hamano wrote:

Show 15 quoted lines

> Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> writes:
> 
> > In most cases, this is just a small annoyance, since it's usually
> > quick and easy to manually switch back to the original
> > branch. However, I have run into at least two cases where it has been
> > a bit more annoying:
> >
> >  1. When on a detached HEAD and running "git rebase HEAD topic", if
> >     you abort the rebase, you will have to look up the old commit in
> >     the reflog.
> 
> Doesn't this merely show a bad discipline? What were you envisioning to
> do to your detached HEAD state if the rebase were to succeed? IOW, if the
> state was so precious, why did you decide to switch to topic and rebase it
> onto that state, without marking?

This usually happens when I see something that looks a bit suspicious in one of my own commits on my topic branch. I then check out that commit to have a look and perhaps run some test. If I find something broken, I would fix it and either amend the commit or create a new commit on top. I would then run "git rebase --onto HEAD HEAD~1 topic" or "git rebase HEAD topic", respectively. If the merge conflicts turn out to be bigger than I expected, I may decide to abort and to instead create a new branch for the commit(s) until I find time/energy.

> > Are there valid cases where the current behavior is bettter?
> 
> I don't particularly like the "when aborted it returns to the original
> location" behaviour even for a single argument "git rebase A" case

This has sometimes annoyed me as well. Maybe a --stop/discard would be a nice alternative to "rf -r .git/(rebase-apply|rebase-merge)"?

Show 21 quoted lines

> At least going back to B conceptually makes more sense in one use case I
> have, which was the original reason I invented rebase with the "checkout B
> and rebase it ono A" shorthand in the first place (see 59e6b23), back when
> I was an active contributor throwing patches at Linus (note that back then
> I didn't have "abort then go back" in the code--and that is why I don't
> care too deeply about this "which branch should I be after aborting?"
> myself).
> 
> The reason I tried to rebase B on A with the short-hand form was because I
> wanted to clean up what is on B; I may say "abort" when my first attempt
> to rebase failed because it was a bit too much to bite at once (e.g. the
> history diverged a bit too much since B forked from A's ancestor).
> 
> But then, the next thing I would want to do in such a case after aborting
> is not to give up and forget about what I needed to do, which is to clean
> up B into a shape easier to merge with the updated codebase that leads to
> A.  I would want to stay on B and examine the situation a bit deeper, and
> try to figuire out a different base (e.g. a bit older commit in the
> history leading to A) to rebase to, so that I can keep up with the other
> branch incrementally without lagging too far behind.  Switching away from
> the original B would be majorly annoying in such a case.

Certainly a valid use case. Maybe the best solution would be to introduce a new kind of --abort (say --abort-to-branch-before-rebase, but with a better name)?

/Martin