git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Joshua Jensen <jjensen@workspacewhiz.com>
Cc: "git\@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: git rebase --abort of an --onto run does not checkout the originating branch
Date: Fri, 22 Oct 2010 12:15:03 -0700	[thread overview]
Message-ID: <7vlj5qkpjc.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <4CC1C34E.8090203@workspacewhiz.com> (Joshua Jensen's message of "Fri\, 22 Oct 2010 11\:01\:02 -0600")

Joshua Jensen <jjensen@workspacewhiz.com> writes:

> git rebase --onto mybranch START_SHA END_SHA
>
> In the middle, I decide to run 'git rebase --abort'.
>
> Just as the documentation states, it performs a checkout of END_SHA as
> the restored branch.  END_SHA has nothing to do with the originating
> branch, and confusion ensues.
>
> Is there a reason why 'git rebase' should not store off the
> originating branch and use that for an --abort, instead of <branch>
> which is END_SHA?

When END_SHA is an actual branch name (which by the way is almost always
how I use --onto in my attempts to transplant my topics), and when I found
out that the conflicts I see while rebasing the topic to a different
starting point (i.e. --onto) is too much to handle for too little gain, I
would not appreciate if --abort took me to the --onto branch, which is
totally uninteresting for the purpose of what I was attempting to do,
namely, to deal with the topic.

If the command took me back to the tip of the topic that I failed to
rebase, I can continue attempting to whip it in shape using different
strategies from there (e.g. merging an older part of upstream into the
topic before merging the topic back to the upstream).

  reply	other threads:[~2010-10-22 19:15 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-22 17:01 git rebase --abort of an --onto run does not checkout the originating branch Joshua Jensen
2010-10-22 19:15 ` Junio C Hamano [this message]
2010-10-28  3:04   ` Joshua Jensen
2010-10-28 16:22     ` Jakub Narebski

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=7vlj5qkpjc.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=jjensen@workspacewhiz.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).