Hi Jonathan, On Thu, 30 Jun 2011, Jonathan Nieder wrote: > Hi Martin, > > Martin von Zweigbergk wrote: > > > The sub commands '--continue', '--skip' or '--abort' may only be used > > standalone according to the documentation. > [...] > > 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 <martin.von.zweigbergk@xxxxxxxxx> --- 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html