Johannes Schindelin <> writes:

>> git continue as a shorthand for `git <relevant-cmd> --continue` sounds great.
> Before we get ahead of ourselves:
> 1) this has nothing to do with the patch series at hand, and
> 2) if we were to introduce `git continue`, we would need to think long and
>    hard about the following issues:
>       I) are there potentially ambiguous <relevant-cmd>s that the user
>          may want to continue?
>       II) what about options? You can say `git rebase --continue
>           --no-ff`, for example, but not `git cherry-pick --continue
>           --no-ff`...
>       III) Would it not be confusing to have a subcommand `continue`
>            that does *not* serve a *single* purpose? It's kinda flying
>            into the face of the Unix philosophy.

The above reasoning applies equally to "git abort".  I do not think
"git continue" would help.

If it were that anything you can do with Git can be --continue'ed
the same way (e.g. all uses one sequencer to rule them all), it
might be achievable, but I do not think it isn't, and will never be.

"git commit" may say "You haven't added anything yet" and refuse to
do anything.  Should "git continue" do "git commit -a" by noticing
that the last thing you tried to do was "git commit" and guess that
it is likely you wanted to commit all changes?  I think not.

Reply via email to