Johannes Schindelin <johannes.schinde...@gmx.de> 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
> 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.