The command could have a mode for specifying START-POINT, so for Git the
command becomes "git checkout -b new-branch-name START-POINT". This
could be on C-u (unless there're other frequent "customization" cases).
The existing API method has no argument for START-POINT.
Maybe every backend could handle its prefix arg directly
from current-prefix-arg? For example,
(defun vc-git-create-tag (dir name branchp)
(if current-prefix-arg (completion-read "Start point: ") ...
Maybe we should add a new argument, an optional one. Then backends which
don't support it can continue working without 'C-u' (we can make sure to
call them with appropriate number of arguments) but will obviously fail
when passed an extra argument. We could even catch the error and report
that the backend doesn't support this feature.
We need to add new optional arguments to another VC-API methods anyway, e.g.
(vc-call-backend backend 'revision-completion-table files)
needs a new argument 'branchp' to avoid the recently added hack
'vc-git-revision-complete-only-branches' that can't be used
in the new command 'vc-switch-branch' by 'vc-read-revision'
(that also needs a new argument 'branchp').
But maybe the command should prompt for START-POINT by default: one doesn't
create branches that often to be bothered by an extra RET, and it can be
useful to verify the branch you are branching off of every time you do
it. That would be my preferred behavior. And the implementation could be
the same if we manage to treat RET as unspecified START-POINT.
Prompting for START-POINT by default is ok. The problem is how to handle
existing backends after adding new optional arguments to VC-API methods.
Maybe first to call with an extra argument, catch an error, then call again
without an extra argument?