[PATCH] rebase: learn --discard subcommand

[PATCH] rebase: learn --discard subcommand

[Martin von Zweigbergk]

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 <martin.von.zweigbergk@gmail.com>
---

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

Re: [PATCH] rebase: learn --discard subcommand

[Ramkumar Ramachandra]

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

Re: [PATCH] rebase: learn --discard subcommand

[Junio C Hamano]

Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> writes:

> ... 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 am not opposed to this particular patch, but thinking about a bigger
picture, I am not sure if we want to solve it this way.

We have multiple "sequence" operations that want to do things in multiple
steps, each of which can stop and give control back to the user, while
leaving some information in the .git directory for it to know where it was
when resuming. I think "am" knows about what "rebase" does (and
vice-versa) so it can detect an attempt to run it while "rebase" is in
still progress and refuse to continue to limit the damage, but if we have
N such "sequence" commands that want to refrain from interfering with each
other, and want to offer an advice to abort the in-progress operation
initiated by other commands, that would mean we would need N * N pieces of
logic to detect other's in-limbo state and offer advices, which would not
scale.

A user who is given back the control from a "sequence" operation may be
confused either (1) immediately after such an event (often some sort of
merge conflict) or (2) much later after first abandoning the working tree
altogether and taking a walk and then coming back to continue working
while forgetting what he was doing. Such a user may want to say "I know I
am in a strange state, give me a state that I can work from, at this point
I do not care about continuing what I was originally doing". The user may
probably not know if "git rebase" was in progress or "git cherry-pick"
was.

"git reset --hard" used to be such a command in simpler times. It removes
MERGE_HEAD unconditionally, so that a confused user can start from scratch
without having to worry about what was in progress. As a devil's advocate,
I am wondering if it is a good idea to simply teach "reset --hard" to also
remove any and all "sequence" cruft (.git/rebase-apply, .git/rebase-merge,
CHERRY_PICK_HEAD; we might have others I do not recall offhand) and be
done with it. It is a large hammer, but it is certainly the easiest to
explain and the simplest to understand way to get out of any troubles.

RE: [PATCH] rebase: learn --discard subcommand

[Tim Mazid]

> From: gitster@pobox.com
> Date: Sat, 28 May 2011 11:51:32 -0700
>
> Martin von Zweigbergk  writes:
>
> > ... 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 am not opposed to this particular patch, but thinking about a bigger
> picture, I am not sure if we want to solve it this way.
>
> We have multiple "sequence" operations that want to do things in multiple
> steps, each of which can stop and give control back to the user, while
> leaving some information in the .git directory for it to know where it was
> when resuming. I think "am" knows about what "rebase" does (and
> vice-versa) so it can detect an attempt to run it while "rebase" is in
> still progress and refuse to continue to limit the damage, but if we have
> N such "sequence" commands that want to refrain from interfering with each
> other, and want to offer an advice to abort the in-progress operation
> initiated by other commands, that would mean we would need N * N pieces of
> logic to detect other's in-limbo state and offer advices, which would not
> scale.
>
> A user who is given back the control from a "sequence" operation may be
> confused either (1) immediately after such an event (often some sort of
> merge conflict) or (2) much later after first abandoning the working tree
> altogether and taking a walk and then coming back to continue working
> while forgetting what he was doing. Such a user may want to say "I know I
> am in a strange state, give me a state that I can work from, at this point
> I do not care about continuing what I was originally doing". The user may
> probably not know if "git rebase" was in progress or "git cherry-pick"
> was.
>
> "git reset --hard" used to be such a command in simpler times. It removes
> MERGE_HEAD unconditionally, so that a confused user can start from scratch
> without having to worry about what was in progress. As a devil's advocate,
> I am wondering if it is a good idea to simply teach "reset --hard" to also
> remove any and all "sequence" cruft (.git/rebase-apply, .git/rebase-merge,
> CHERRY_PICK_HEAD; we might have others I do not recall offhand) and be
> done with it. It is a large hammer, but it is certainly the easiest to
> explain and the simplest to understand way to get out of any troubles.

I'd just like to say that I sometime use "git reset --hard" in the middle
of a "git rebase" when I want to get rid of some changes completely.
Now, I'm not saying that this is the best way of doing it ("git checkout --"
is probably far superior?), but I daresay that there are some users out
there who will be surprised by the new behaviour of "git reset --hard".

Having said that, before I knew that "git reset --hard" could be used
in the middle of a rebase without aborting the reset, I did try to use it
to abort the rebase, because, as you said, it seems to be "uh oh" button
in git.

So it's a bit of a toss-up really.

Having said that, I would support making "reset --hard" abort rebases,
on the condition that there are some _big_ warnings somewhere about
the change in behaviour.


Tim.

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

Re: [PATCH] rebase: learn --discard subcommand

[Jonathan Nieder]

Hi,

Tim Mazid wrote:

> I'd just like to say that I sometime use "git reset --hard" in the middle
> of a "git rebase" when I want to get rid of some changes completely.
> Now, I'm not saying that this is the best way of doing it ("git checkout --"
> is probably far superior?)

 . "git checkout -- ." to discard unadded changes
 . "git checkout HEAD -- ." to discard uncommitted changes
 . "git reset --keep HEAD^" to work against a different commit
 . "git reset --merge" to discard a merge resolution in progress

While I also would be happy to see "git reset --hard" to abort
am/rebase, I see two problems, one with an obvious solution, the other
not:

1. It would be a big change in behavior that directly goes against
muscle memory, as you mentioned.  This part could be mitigated by
providing "undo" functionality (e.g., renaming the .git/rebase-merge
directory instead of deleting it) and printing advice including a
command that gets the sequencer state back.

2. It does not help people like me who are fearful about scribbling
over accidentally unstaged or uncommitted changes.  This could be
mitigated by also providing forget-sequence functionality through
separate commands like "git rebase --discard".

Re: [PATCH] rebase: learn --discard subcommand

[Jonathan Nieder]

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

RE: [PATCH] rebase: learn --discard subcommand

[Tim Mazid]

> Date: Sat, 28 May 2011 18:08:44 -0500
> From: jrnieder@gmail.com
> 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.

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
 		 	   		  

Re: [PATCH] rebase: learn --discard subcommand

[Martin von Zweigbergk]

On Sat, 28 May 2011, Ramkumar Ramachandra wrote:

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

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

Re: [PATCH] rebase: learn --discard subcommand

[Martin von Zweigbergk]

On Sat, 28 May 2011, Junio C Hamano wrote:

> Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> writes:
> 
> > ... 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 am not opposed to this particular patch, but thinking about a bigger
> picture, I am not sure if we want to solve it this way.
> 
> We have multiple "sequence" operations that want to do things in multiple
> steps, each of which can stop and give control back to the user, while
> leaving some information in the .git directory for it to know where it was
> when resuming. I think "am" knows about what "rebase" does (and
> vice-versa) so it can detect an attempt to run it while "rebase" is in
> still progress and refuse to continue to limit the damage, but if we have
> N such "sequence" commands that want to refrain from interfering with each
> other, and want to offer an advice to abort the in-progress operation
> initiated by other commands, that would mean we would need N * N pieces of
> logic to detect other's in-limbo state and offer advices, which would not
> scale.

Makes sense. I think someone once suggested to have a .git/inprogress
directory that would contain some basic information that could be used
to diagnose in a generic way what operation might be in progress.

> A user who is given back the control from a "sequence" operation may be
> confused either (1) immediately after such an event (often some sort of
> merge conflict) or (2) much later after first abandoning the working tree
> altogether and taking a walk and then coming back to continue working
> while forgetting what he was doing. Such a user may want to say "I know I
> am in a strange state, give me a state that I can work from, at this point
> I do not care about continuing what I was originally doing". The user may
> probably not know if "git rebase" was in progress or "git cherry-pick"
> was.

Maybe the recent patch [1] about adding information to git status
about any ongoing operation would help. I'm not sure, but I think I
would personally be a bit hesitant to cancel the current sequence
operation without first checking what it was. OTOH, if I don't even
remember starting a rebase operation, maybe knowing whether it was a
rebase or an am operation might not help much. But if the message from
git status would actually say something like "rebase in progress:
[2/3] War on nbsp: a bit of retreat", then that might help more in
making a decision to cancel or not.


 [1] http://thread.gmane.org/gmane.comp.version-control.git/172919

Re: [PATCH] rebase: learn --discard subcommand

[Jakub Narebski]

Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> writes:

> Maybe the recent patch [1] about adding information to git status
> about any ongoing operation would help. I'm not sure, but I think I
> would personally be a bit hesitant to cancel the current sequence
> operation without first checking what it was. OTOH, if I don't even
> remember starting a rebase operation, maybe knowing whether it was a
> rebase or an am operation might not help much. But if the message from
> git status would actually say something like "rebase in progress:
> [2/3] War on nbsp: a bit of retreat", then that might help more in
> making a decision to cancel or not.
> 
>  [1] http://thread.gmane.org/gmane.comp.version-control.git/172919

Such information could be not enough.  I understand that "git status"
output space is limited, but it would be nice if e.g. "git status -v"
described current state in more detail:

  rebase in progress: [2/3] War on nbsp: a bit of retreat"
  rebasing xx/foo --onto master~5

It would describe which branch were we rebasing, and on what commit
(preferring for name-rev description to start from branch we were
rebasing onto, if possible).

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: [PATCH] rebase: learn --discard subcommand

[Martin von Zweigbergk]

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.

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

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

Re: [PATCH] rebase: learn --discard subcommand

[Jonathan Nieder]

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.

Re: [PATCH] rebase: learn --discard subcommand

[Michael Haggerty]

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/

Re: [PATCH] rebase: learn --discard subcommand

[Michael Haggerty]

On 05/28/2011 08:51 PM, Junio C Hamano wrote:
> "git reset --hard" used to be such a command in simpler times. It removes
> MERGE_HEAD unconditionally, so that a confused user can start from scratch
> without having to worry about what was in progress. As a devil's advocate,
> I am wondering if it is a good idea to simply teach "reset --hard" to also
> remove any and all "sequence" cruft (.git/rebase-apply, .git/rebase-merge,
> CHERRY_PICK_HEAD; we might have others I do not recall offhand) and be
> done with it. It is a large hammer, but it is certainly the easiest to
> explain and the simplest to understand way to get out of any troubles.

If it would be desirable to separate the resetting of the working tree
from the resetting of any in-progress operation, perhaps "git reset
--abort" (by analogy with "git reset --abort" etc) would be a possible
spelling of the latter.  To reset any in-progress operations *and* reset
the working tree, on could use "git reset --hard --abort".

I strongly agree with another poster that it would be useful if "git
status" would print information about in-progress operations.

Michael

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

Re: [PATCH] rebase: learn --discard subcommand

[Miles Bader]

Jonathan Nieder <jrnieder@gmail.com> 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.

Re: [PATCH] rebase: learn --discard subcommand

[Tim Mazid]

[-- Attachment #1: Type: text/plain, Size: 1219 bytes --]

On Mon, May 30, 2011 at 06:46:48AM +0200, Michael Haggerty wrote:
> 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

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] rebase: learn --discard subcommand

[Michael Haggerty]

On 05/30/2011 07:14 AM, Tim Mazid wrote:
> On Mon, May 30, 2011 at 06:46:48AM +0200, Michael Haggerty wrote:
>> 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
> 
> 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/