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: Jonathan Nieder <hidden>
Date: 2016-06-15 22:51:32

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?

*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?

[1] http://thread.gmane.org/gmane.comp.version-control.git/164241/focus=166684
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help