[PATCH] rebase: learn --discard subcommand

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).

Signed-off-by: Martin von Zweigbergk <redacted>
---

A long time ago I said I wished that 'git rebase --abort' would move
back to the where HEAD was when the rebase was initiated, instead of
moving back to the branch that was about to be rebased (which may be
different for "git rebase $upstream $branch"). 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
don't feel strongly about this patch, but I would probably also use
this subcommand once in a while. However, maybe the greatest value in
it is that we don't have to tell users to mess with the .git
directory?

I used "rm -r" without -f to match how it is done in --abort, but
maybe -f should be used? That is what we recommend to the end-user to
use today.

A difference from --abort is that --discard does not clear
rerere. Need this be mentioned in the documentation?

I have not been involved in Ramkumar's work on the sequencer to know
if and how this might impact it.


 Documentation/git-rebase.txt |    5 ++++-
 git-rebase.sh                |   17 +++++++++++------
 2 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 9a075bc..e841c21 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt

@@ -13,7 +13,7 @@ SYNOPSIS
 'git rebase' [-i | --interactive] [options] --onto <newbase>
 	--root [<branch>]
 
-'git rebase' --continue | --skip | --abort
+'git rebase' --continue | --skip | --abort | --discard
 
 DESCRIPTION
 -----------

@@ -238,6 +238,9 @@ leave out at most one of A and B, in which case it defaults to HEAD.
 --skip::
 	Restart the rebasing process by skipping the current patch.
 
+--discard::
+	Abort the rebase operation without restoring the original branch.
+
 -m::
 --merge::
 	Use merging strategies to rebase.  When the recursive (default) merge

diff --git a/git-rebase.sh b/git-rebase.sh
index 7a54bfc..befee92 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh

@@ -32,7 +32,7 @@ OPTIONS_KEEPDASHDASH=
 OPTIONS_SPEC="\
 git rebase [-i] [options] [--onto <newbase>] [<upstream>] [<branch>]
 git rebase [-i] [options] --onto <newbase> --root [<branch>]
-git-rebase [-i] --continue | --abort | --skip
+git-rebase [-i] --continue | --abort | --skip | --discard
 --
  Available options are
 v,verbose!         display a diffstat of what changed upstream

@@ -60,6 +60,7 @@ C=!                passed to 'git apply'
 continue!          continue rebasing process
 abort!             abort rebasing process and restore original branch
 skip!              skip current patch and continue rebasing process
+discard!           abort rebasing process, but do not restore original branch
 "
 . git-sh-setup
 set_reflog_action rebase

@@ -93,7 +94,7 @@ in_progress=
 type=
 # One of {"$GIT_DIR"/rebase-apply, "$GIT_DIR"/rebase-merge}
 state_dir=
-# One of {'', continue, skip, abort}, as parsed from command line
+# One of {'', continue, skip, abort, discard}, as parsed from command line
 action=
 preserve_merges=
 autosquash=

@@ -206,7 +207,7 @@ do
 	--verify)
 		ok_to_skip_pre_rebase=
 		;;
-	--continue|--skip|--abort)
+	--continue|--skip|--abort|--discard)
 		test $total_argc -eq 2 || usage
 		action=${1##--}
 		;;

@@ -340,6 +341,10 @@ abort)
 	rm -r "$state_dir"
 	exit
 	;;
+discard)
+	rm -r "$state_dir"
+	exit
+	;;
 esac
 
 # Make sure no rebase is in progress

@@ -349,9 +354,9 @@ then
 It seems that there is already a '"${state_dir##*/}"' directory, and
 I wonder if you are in the middle of another rebase.  If that is the
 case, please try
-	git rebase (--continue | --abort | --skip)
-If that is not the case, please
-	rm -fr '"$state_dir"'
+	git rebase (--continue | --abort | --skip | --discard)
+If that is not the case, please run
+	git rebase --discard
 and run me again.  I am stopping in case you still have something
 valuable there.'
 fi

-- 
1.7.4.79.gcbe20

Hi Martin,

Martin von Zweigbergk writes:

A long time ago I said I wished that 'git rebase --abort' would move
back to the where HEAD was when the rebase was initiated, instead of
moving back to the branch that was about to be rebased (which may be
different for "git rebase $upstream $branch"). 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
don't feel strongly about this patch, but I would probably also use
this subcommand once in a while. However, maybe the greatest value in
it is that we don't have to tell users to mess with the .git
directory?

Interesting. Yes, I usually remove the state file by hand too. In view
of "git rebase --interactive" being a porcelain command, I don't know
if it's alright to drop the user into a detached HEAD state.

I used "rm -r" without -f to match how it is done in --abort, but
maybe -f should be used? That is what we recommend to the end-user to
use today.

If you've verified that a rebase is already in progress, I don't see
the point of using '-f'. Otherwise, it should error out and say that
"no rebase is in progress", like the other command-line options
currently do.

A difference from --abort is that --discard does not clear
rerere. Need this be mentioned in the documentation?

It depends on what you're expecting the user to do in this detached
HEAD state, no?

I have not been involved in Ramkumar's work on the sequencer to know
if and how this might impact it.

It'll have no impact on the Sequencer work. Thanks.

-- Ram

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.

[...]

+--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

Date: Sat, 28 May 2011 18:08:44 -0500
From: jrnieder@gmail.com
Martin von Zweigbergk wrote:

quoted

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.

quoted

--- 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.

[...]

quoted

+--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.

How about "git rebase --stop"?

I think the word "stop" has the implication that you don't go
anywhere, but also that you abort doing whatever it is you were
(in this case, the rebase).

And as I said before, I don't like the idea of changing the
behaviour of already existing (and widely used) commands and
options; even if, as in my case, they're not always used correctly.


Tim.

() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
 		 	   		  

On Sat, 28 May 2011, Ramkumar Ramachandra wrote:

quoted

I used "rm -r" without -f to match how it is done in --abort, but
maybe -f should be used? That is what we recommend to the end-user to
use today.

If you've verified that a rebase is already in progress, I don't see
the point of using '-f'. Otherwise, it should error out and say that
"no rebase is in progress", like the other command-line options
currently do.

Yep, it does verify that a rebase is in progress. I think rm without
-f still asks the user to confirm if the file is read-only. I can't
see why that would happen, so maybe it's good to have the user confirm
it it does happen.

quoted

A difference from --abort is that --discard does not clear
rerere. Need this be mentioned in the documentation?

It depends on what you're expecting the user to do in this detached
HEAD state, no?

The subcommand will most likely be run when the user had forgotten the
current rebase and tries to start a new rebase and get's the message
that a rebase is already in progress. At this point, the user is not
necessarily in a detached HEAD state any more.

/Martin

On Sat, 28 May 2011, Jonathan Nieder wrote:

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.

Maybe --stop as Tim suggested, but I think that also makes it sound
like we're dropping the rest of the patches. Other names would be
--cancel or --forget.

quoted

--- 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.

[...]

quoted

+--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?

The --abort subcommand is currently described as "Restore the original
branch and abort the rebase operation.", so that would be in need of
the same clarification.

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.

?

Thanks. I like it. Maybe with "... or if you have moved to an
unrelated commit" or something like that be added to the end.

Agh, "git rebase --abort --keep-head" feels a little too long to be
memorable.  Still, hope that helps.

I intended --discard to be used _instead_ of --abort. Do you think it
makes more sense to have it as an option to --abort or was it just
that the word "subcommand" confused you? I meant it as "subcommand of
git rebase".


/Martin

Martin von Zweigbergk wrote:

I intended --discard to be used _instead_ of --abort. Do you think it
makes more sense to have it as an option to --abort or was it just
that the word "subcommand" confused you? I meant it as "subcommand of
git rebase".

I agree that --abort-keeping-head is nicer than --abort --keep-head.
The latter was just a little easier to document.

Sorry, I'm terrible at names.  --forget, --discard, and --done have
the same problem of making the reader wonder what is going to be
forgotten and what remembered.

On 05/29/2011 01:08 AM, Jonathan Nieder wrote:

Agh, "git rebase --abort --keep-head" feels a little too long to be
memorable.  Still, hope that helps.

It seems like the distinction is analogous to "git reset --soft", so maybe

    git rebase --abort --soft

?

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/

Jonathan Nieder [off-list ref] writes:

Agh, "git rebase --abort --keep-head" feels a little too long to be
memorable.  Still, hope that helps.

"--abort --stay"...?

-miles

-- 
Cat, n. A soft, indestructible automaton provided by nature to be kicked when
things go wrong in the domestic circle.

On Mon, May 30, 2011 at 06:46:48AM +0200, Michael Haggerty wrote:

On 05/29/2011 01:08 AM, Jonathan Nieder wrote:

quoted

Agh, "git rebase --abort --keep-head" feels a little too long to be
memorable.  Still, hope that helps.

It seems like the distinction is analogous to "git reset --soft", so maybe

    git rebase --abort --soft

Well, the only problem with that is the "--soft" option refers to the
"reset" command given to git, whereas in your proposed syntax, the
"--soft" option refers to the _other_ option, "--abort".

This may seem a little nit-picky, but such a difference could lead to
confusion.  Perhaps "--soft-abort" or "--soft-abort" would be better?  A
single option to the "git rebase" command rather than a "sub-option"
given to another option.

It just seems to me that all the git commands work this way; "git
command --options-to-command".  An option to another option just seems
too confusing.

Of course, there's the floodgate problem; once you have options to
options, are you going to have options to options to options, ad
infinitum?

-- 
Tim

() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org   - against proprietary attachments

On 05/30/2011 07:14 AM, Tim Mazid wrote:

On Mon, May 30, 2011 at 06:46:48AM +0200, Michael Haggerty wrote:

quoted

On 05/29/2011 01:08 AM, Jonathan Nieder wrote:

quoted

Agh, "git rebase --abort --keep-head" feels a little too long to be
memorable.  Still, hope that helps.

It seems like the distinction is analogous to "git reset --soft", so maybe

    git rebase --abort --soft

Well, the only problem with that is the "--soft" option refers to the
"reset" command given to git, whereas in your proposed syntax, the
"--soft" option refers to the _other_ option, "--abort".

This may seem a little nit-picky, but such a difference could lead to
confusion.  Perhaps "--soft-abort" or "--soft-abort" would be better?  A
single option to the "git rebase" command rather than a "sub-option"
given to another option.

To be even more nit-picky :-), --abort (and --continue) are really
subcommands of rebase.  The fact that they are implemented as options is
the original source of the inconsistency.  Of course this cannot be
changed because "git rebase abort" already has a different meaning.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/