Thread (105 messages) flat view 105 messages, 10 authors, 2016-06-15

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help