bug#50344: C-x v keybinding for vc-print-branch-log

[Juri Linkov]

>>> 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?