Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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.