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

[Ramkumar Ramachandra <artagnon@gmail.com>]

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