bug#57807: 29.0.50; Make vc-print-branch-log able to log multiple branches

[Juri Linkov]

> vc-git-log-edit-mode is already able to properly understand git-log(1)

I suppose vc-git-log-view-mode, not vc-git-log-edit-mode?

> output which logs multiple branches.  Here's a hack to demonstrate that:
>
>     (let ((default-directory "~/src/emacs/")
>           (vc-git-log-switches
>            (cons "origin/scratch/posix-spawn" vc-git-log-switches)))
>       (call-process-shell-command "git branch -f tmp 4b2ca6bfc0")
>       (vc-print-branch-log "tmp"))
>
> (4b2ca6bfc0 is an old tip of master close to scratch/posix-spawn.)

Is this equivalent to `M-& git log origin/scratch/posix-spawn 4b2ca6bfc0`,
then enabling vc-git-log-view-mode in the output buffer?

> An example of a case in which it is useful to produce logs like this is
> when you're trying to figure out how several feature branches relate to
> each other and to the trunk.

I never encountered anything like this.  I wonder if this is a common need?

> I don't think the idea of producing a log showing more than one branch
> at once is fundamentally git-specific.  So I would like to extend
> vc-print-branch-log to allow logging more than one branch, or
> alternatively, add a vc-print-branch-logs command.

Maybe vc-print-branch-logs, to keep the original vc-print-branch-log
uncomplicated.

> I believe that there are two design issues, on which I'm requesting
> review/input:
>
> (1) Extending the VC history functions API to permit expressing a
> request for the backend to print a log of multiple branches.  We could
> allow the START-REVISION argument to `print-log' to take a list of
> branches, or add an additional optional argument
> ADDITIONAL-START-REVISIONS.  The latter seems more robust to me.
>
> (2) How could vc-print-branch-log prompt the user for multiple branch
> names?  Magit has the user separate branch names with commas, offering
> completion for each branch name.  But I suppose commas never appearing
> in branch names is git-specific.  So the command could prompt the user
> repeatedly for branch names, until the user hits RET to input a
> zero-length branch name, indicating they've input them all.

Maybe by using completing-read-multiple with branch names separated
by crm-separator, not necessarily comma?