Re: [PATCH 09/22] sequencer: completely revamp the "todo" script parsing

Johannes Schindelin [off-list ref] writes:

quoted

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.