Re: [PATCH v2 07/31] rebase: stricter check of standalone sub command
From: Martin von Zweigbergk <hidden>
Date: 2016-06-15 22:51:32
Subsystem:
the rest · Maintainer:
Linus Torvalds
Hi Jonathan, On Thu, 30 Jun 2011, Jonathan Nieder wrote:
Hi Martin, Martin von Zweigbergk wrote:quoted
The sub commands '--continue', '--skip' or '--abort' may only be used standalone according to the documentation.[...]quoted
Is this too simplistic? Do we forsee that we want to support passing options when resuming a rebase? Is it better to check for each other option that it is not passed (i.e. no '-v', no '-s' etc.)? Might some users be depending on the current behavior, even though it is undocumented?Yes. I have no clue why, but my fingers are wired to do git rebase -i --continue when resuming an interactive rebase. So with v1.7.6, I use two commands instead of one. It's possible that I was crazy, and we should just mention this in the release notes and move on. Another possibility would be to make "git rebase -i --continue" mean "check if in the middle of an interactive rebase, and if so, continue". Yet another possibility would be to allow transforming a non-interactive rebase into an interactive one after a conflict with that command (though I can't imagine why someone would want to). I'm tempted to say the first way (keeping the command broken and documenting the change) is the way to go, since it means it would be possible to make commands like this mean something else in the future. What do you think?
I think it feels like 'git rebase -i --continue' to resume a non-interactive rebase should be an error until we actually support transforming it into an interactive rebase (if ever). I agree that if the rebase was already interactive, it would not harm to accept it. OTOH, since the -i means nothing in this context, I don't see much need to accept it either. In short, I agree with you that documenting it is enough. Is the below patch what you had in mind?
*searches* Ah, it seems you already wrote a patch at [1]. The commit message says it fails for "-i --continue" but I don't any code doing that; what am I missing?
That patch was never accepted, but 95135b0 (rebase: stricter check of standalone sub command, 2011-02-06) was.
[1] http://thread.gmane.org/gmane.comp.version-control.git/164241/focus=166684
-- >8 -- Subject: [PATCH] rebase usage: subcommands can not be combined with -i Since 95135b0 (rebase: stricter check of standalone sub command, 2011-02-06), git-rebase has not allowed to use -i together with e.g. --continue. Yet, when rebase started using OPTIONS_SPEC in 45e2acf (rebase: define options in OPTIONS_SPEC, 2011-02-28), the usage message included git-rebase [-i] --continue | --abort | --skip Remove the "[-i]" from this line. Signed-off-by: Martin von Zweigbergk <redacted> --- git-rebase.sh | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index d7855ea..6afc596 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 --continue | --abort | --skip -- Available options are v,verbose! display a diffstat of what changed upstream
--
1.7.5.3.640.gd1066