GNU bug report logs - #50344
C-x v keybinding for vc-print-branch-log

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Juri Linkov <juri <at> linkov.net>
Cc: 50344 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>, Filipp Gunbin <fgunbin <at> fastmail.fm>
Subject: bug#50344: C-x v keybinding for vc-print-branch-log
Date: Thu, 7 Oct 2021 03:57:47 +0300

On 06.10.2021 10:29, Juri Linkov wrote:
>>>> 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').

This will probably help in vc-switch-branch (when the user wants to 
retrieve a tag, I guess they will use the tag-specific command).

Not sure about other places: if we're talking about the START-POSITION 
argument, I suppose it is possible that the user will want to start a 
branch from a tag instead. Or any other kind of ref, but "raw" commit 
hashes aren't helpful in completion anyway.

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

Yes, that's the method I was thinking of.

Previous Next

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