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

[Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>]

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