Re: [PATCH v2 07/31] rebase: stricter check of standalone sub command

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

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@gmail.com>
---
 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