GNU bug report logs - #57807
29.0.50; Make vc-print-branch-log able to log multiple branches

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#57807: closed (29.0.50; Make vc-print-branch-log able to log
 multiple branches)
Date: Wed, 21 Sep 2022 19:40:01 +0000

[Message part 1 (text/plain, inline)]

Your message dated Wed, 21 Sep 2022 12:39:31 -0700
with message-id <87o7v8ple4.fsf <at> melete.silentflame.com>
and subject line Re: bug#57807: 29.0.50; Make vc-print-branch-log able to log multiple branches
has caused the debbugs.gnu.org bug report #57807,
regarding 29.0.50; Make vc-print-branch-log able to log multiple branches
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
57807: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57807
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; Make vc-print-branch-log able to log multiple branches
Date: Wed, 14 Sep 2022 10:19:48 -0700

Hello,

vc-git-log-edit-mode is already able to properly understand git-log(1)
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.)

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

-- 
Sean Whitton

[Message part 3 (message/rfc822, inline)]

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Juri Linkov <juri <at> linkov.net>, 57807-done <at> debbugs.gnu.org
Subject: Re: bug#57807: 29.0.50; Make vc-print-branch-log able to log
 multiple branches
Date: Wed, 21 Sep 2022 12:39:31 -0700

On Wed 21 Sep 2022 at 09:52PM +03, Juri Linkov wrote:

> Adding vc-pre-command-functions as a counterpart of the existing
> vc-post-command-functions is a nice solution.  I tested everything,
> and there are no more problems.  Thanks for implementing this feature.

Thank you for testing it.

> After you will push it, it would be good also to try to generalize it
> to other vc commands.  The problem is that some commands already use
> C-u for other purposes, such as 'C-u C-x v L' asks for a limit.  What
> would be a possible way to set vc-want-edit-command-p without using a
> prefix arg?  Maybe to add a new command that will only set
> vc-want-edit-command-p for the next vc command, and bind it to
> e.g. 'C-x v c'.  Then 'C-x v c C-x v L' will allow editing the root
> log command.

Right.  It would be good to find a way to make all this consistent.
It's unfortunate that C-x v l and C-x v P were different to begin with.

Regarding your idea, how about 'C-x V V'?  It's easier to type, won't
clash with another command we might want to put on 'c', and feels a bit
like C-x 4 4, C-x 5 5 etc.  Though, to be honest, I'd prefer it if we
could come up with something involving multiple 'C-u'.

-- 
Sean Whitton

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.