From: Martin von Zweigbergk <martin.von.zweigbergk@gmail•com>
To: Junio C Hamano <gitster@pobox•com>
Cc: Martin von Zweigbergk <martin.von.zweigbergk@gmail•com>,
git@vger•kernel.org
Subject: Re: [RFD] make rebase abort to original branch, not rebased branch
Date: Sun, 13 Mar 2011 10:58:08 -0400 (EDT) [thread overview]
Message-ID: <alpine.DEB.2.00.1103131013370.15442@debian> (raw)
In-Reply-To: <7vmxkzijpt.fsf@alter.siamese.dyndns.org>
On Sat, 12 Mar 2011, Junio C Hamano wrote:
> 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)"?
> 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
next prev parent reply other threads:[~2011-03-13 14:58 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-13 3:58 [RFD] make rebase abort to original branch, not rebased branch Martin von Zweigbergk
2011-03-13 7:05 ` Junio C Hamano
2011-03-13 7:46 ` Junio C Hamano
2011-03-13 14:58 ` Martin von Zweigbergk [this message]
2011-03-13 15:27 ` Alexander Miseler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.00.1103131013370.15442@debian \
--to=martin.von.zweigbergk@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox