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

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: May 28, 2011, 13:15 UTC
Message-ID: <BANLkTim-Wva018BFeTUPqZuiK02-X01XJQ@mail.gmail.com>
In-Reply-To: <1306551495-26685-1-git-send-email-martin.von.zweigbergk@gmail.com>

Hi Martin,

Martin von Zweigbergk writes:

Show 10 quoted lines

> 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