From: Jonathan Nieder <jrnieder@gmail.com>
To: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>,
Ramkumar Ramachandra <artagnon@gmail.com>,
Tim Mazid <timmazid@hotmail.com>
Subject: Re: [PATCH] rebase: learn --discard subcommand
Date: Sat, 28 May 2011 18:08:44 -0500 [thread overview]
Message-ID: <20110528230844.GA31498@elie> (raw)
In-Reply-To: <1306551495-26685-1-git-send-email-martin.von.zweigbergk@gmail.com>
Hi,
Martin von Zweigbergk wrote:
> Teach git-rebase the --discard subcommand, which is similar to
> --abort, but does not move back to the original branch. Suggest this
> new subcommand to the user where we currently suggest to delete
> $GIT_DIR/rebase-apply (or rebase-merge).
Good idea.
At first the name --discard made me think it was going to move back to
the original branch and discard the reset of the patch series being
rebased. Not sure what a better name would be, though.
> --- a/Documentation/git-rebase.txt
> +++ b/Documentation/git-rebase.txt
> @@ -238,6 +238,9 @@ leave out at most one of A and B, in which case it defaults to HEAD.
[...]
> +--discard::
> + Abort the rebase operation without restoring the original branch.
A reader without a complete mental model for what "git rebase" does
could be very confused by this. One might think: does this mean that
git has been scribbling over the original branch, and this switch
almost completely cancels that but leaves the branch still
scribbled-on?
How about something like:
--keep-head::
When aborting a rebase, do not check out the original branch
but leave the HEAD alone. This can be useful if you forgot
about a conflicted or interactive rebase in progress and have
been committing on top of one of the commits being replayed.
?
Agh, "git rebase --abort --keep-head" feels a little too long to be
memorable. Still, hope that helps.
Ciao,
Jonathan
next prev parent reply other threads:[~2011-05-28 23:09 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-28 2:58 [PATCH] rebase: learn --discard subcommand Martin von Zweigbergk
2011-05-28 13:15 ` Ramkumar Ramachandra
2011-05-29 12:50 ` Martin von Zweigbergk
2011-05-28 18:51 ` Junio C Hamano
2011-05-28 20:26 ` Tim Mazid
2011-05-28 22:50 ` Jonathan Nieder
2011-05-29 13:14 ` Martin von Zweigbergk
2011-05-29 13:41 ` Jakub Narebski
2011-05-30 4:50 ` Michael Haggerty
2011-05-28 23:08 ` Jonathan Nieder [this message]
2011-05-29 9:30 ` Tim Mazid
2011-05-29 17:28 ` Martin von Zweigbergk
2011-05-29 18:58 ` Jonathan Nieder
2011-05-30 4:46 ` Michael Haggerty
2011-05-30 5:14 ` Tim Mazid
2011-05-30 8:44 ` Michael Haggerty
2011-05-30 5:01 ` Miles Bader
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=20110528230844.GA31498@elie \
--to=jrnieder@gmail.com \
--cc=artagnon@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=martin.von.zweigbergk@gmail.com \
--cc=timmazid@hotmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.