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

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

[Juri Linkov]

While vc-print-branch-log is a frequently used command, it still has no
keybinding in vc-prefix-map.  But it has a keybinding in vc-dir-mode-map.
Many keys are already shared between vc-prefix-map and vc-dir-mode-map, e.g.:

  (defvar vc-dir-mode-map
    ;; VC commands
    (define-key map "v" #'vc-next-action)   ;; C-x v v
    (define-key map "=" #'vc-diff)	   ;; C-x v =
    (define-key map "D" #'vc-root-diff)	   ;; C-x v D
    (define-key map "i" #'vc-register)	   ;; C-x v i
    (define-key map "+" #'vc-update)	   ;; C-x v +
    (define-key map "P" #'vc-push)	   ;; C-x v P
    (define-key map "l" #'vc-print-log)	   ;; C-x v l
    (define-key map "L" #'vc-print-root-log) ;; C-x v L
    (define-key map "I" #'vc-log-incoming)   ;; C-x v I
    (define-key map "O" #'vc-log-outgoing)   ;; C-x v O

Also vc-dir-mode-map has branch keys:

    (let ((branch-map (make-sparse-keymap)))
      (define-key map "B" branch-map)
      (define-key branch-map "c" #'vc-create-tag)
      (define-key branch-map "l" #'vc-print-branch-log)
      (define-key branch-map "s" #'vc-retrieve-tag))

So it makes sense to copy branch keys from vc-dir-mode-map
to vc-prefix-map:

diff --git a/lisp/vc/vc-hooks.el b/lisp/vc/vc-hooks.el
index 4b3c829a2c..d039c400c5 100644
--- a/lisp/vc/vc-hooks.el
+++ b/lisp/vc/vc-hooks.el
@@ -865,6 +865,9 @@ vc-prefix-map
   (let ((map (make-sparse-keymap)))
     (define-key map "a" #'vc-update-change-log)
     (define-key map "b" #'vc-switch-backend)
+    (define-key map "Bc" #'vc-create-tag)
+    (define-key map "Bl" #'vc-print-branch-log)
+    (define-key map "Bs" #'vc-retrieve-tag)
     (define-key map "d" #'vc-dir)
     (define-key map "g" #'vc-annotate)
     (define-key map "G" #'vc-ignore)

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

[Dmitry Gutov]

On 02.09.2021 21:43, Juri Linkov wrote:
> So it makes sense to copy branch keys from vc-dir-mode-map
> to vc-prefix-map:
> 
> diff --git a/lisp/vc/vc-hooks.el b/lisp/vc/vc-hooks.el
> index 4b3c829a2c..d039c400c5 100644
> --- a/lisp/vc/vc-hooks.el
> +++ b/lisp/vc/vc-hooks.el
> @@ -865,6 +865,9 @@ vc-prefix-map
>     (let ((map (make-sparse-keymap)))
>       (define-key map "a" #'vc-update-change-log)
>       (define-key map "b" #'vc-switch-backend)
> +    (define-key map "Bc" #'vc-create-tag)
> +    (define-key map "Bl" #'vc-print-branch-log)
> +    (define-key map "Bs" #'vc-retrieve-tag)
>       (define-key map "d" #'vc-dir)
>       (define-key map "g" #'vc-annotate)
>       (define-key map "G" #'vc-ignore)

Makes sense to me as well. Thanks!

Do we want to remove the vc-retrieve-tag from 'C-x v r' sometime later? 
It does have a dual function (branches/tags and commits as well), but it 
would be nice to free this combination.

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

[Juri Linkov]

>> +    (define-key map "Bc" #'vc-create-tag)
>> +    (define-key map "Bl" #'vc-print-branch-log)
>> +    (define-key map "Bs" #'vc-retrieve-tag)
>
> Makes sense to me as well. Thanks!
>
> Do we want to remove the vc-retrieve-tag from 'C-x v r' sometime later?

I guess, yes.  But is it possible to deprecate a keybinding like
there are 'make-obsolete' for functions and 'make-obsolete-variable'?

> It does have a dual function (branches/tags and commits as well), but it would
> be nice to free this combination.

Do you mean to create two separate commands and separate keybindings
for switching a branch vs tags?

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

[Dmitry Gutov]

On 03.09.2021 11:15, Juri Linkov wrote:
>>> +    (define-key map "Bc" #'vc-create-tag)
>>> +    (define-key map "Bl" #'vc-print-branch-log)
>>> +    (define-key map "Bs" #'vc-retrieve-tag)
>>
>> Makes sense to me as well. Thanks!
>>
>> Do we want to remove the vc-retrieve-tag from 'C-x v r' sometime later?
> 
> I guess, yes.  But is it possible to deprecate a keybinding like
> there are 'make-obsolete' for functions and 'make-obsolete-variable'?

Probably not. Only by writing in the NEWS, or something.

>> It does have a dual function (branches/tags and commits as well), but it would
>> be nice to free this combination.
> 
> Do you mean to create two separate commands and separate keybindings
> for switching a branch vs tags?

No, just removing one binding. It's not urgent or very important, just 
something to think about.

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

[Juri Linkov]

>> +    (define-key map "Bc" #'vc-create-tag)
>> +    (define-key map "Bl" #'vc-print-branch-log)
>> +    (define-key map "Bs" #'vc-retrieve-tag)
>
> Do we want to remove the vc-retrieve-tag from 'C-x v r' sometime later? It
> does have a dual function (branches/tags and commits as well), but it would
> be nice to free this combination.

I think we want more to remove another duplicate key 'C-x v s'
because then we could bind it to 'vc-log-search'.

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

[Dmitry Gutov]

On 03.09.2021 19:18, Juri Linkov wrote:
> I think we want more to remove another duplicate key 'C-x v s'
> because then we could bind it to 'vc-log-search'.

That works for me. And indeed vc-log-search seems more important.

What do others think?

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

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 03.09.2021 19:18, Juri Linkov wrote:
>> I think we want more to remove another duplicate key 'C-x v s'
>> because then we could bind it to 'vc-log-search'.
>
> That works for me. And indeed vc-log-search seems more important.
>
> What do others think?

Then it would be only on `B c' in vc-dir-mode?  `C-x v s' isn't very
mnemonic, but would removing it from global map inconvenience people?
(I've never used it myself.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Juri Linkov]

>>> I think we want more to remove another duplicate key 'C-x v s'
>>> because then we could bind it to 'vc-log-search'.
>>
>> That works for me. And indeed vc-log-search seems more important.
>>
>> What do others think?
>
> Then it would be only on `B c' in vc-dir-mode?  `C-x v s' isn't very
> mnemonic, but would removing it from global map inconvenience people?
> (I've never used it myself.)

Indeed, it seems there is no way to remove old keybindings, especially
by rebinding them to other commands, so I propose to add new keybindings:

diff --git a/lisp/vc/vc-hooks.el b/lisp/vc/vc-hooks.el
index 4b3c829a2c..4d3f642796 100644
--- a/lisp/vc/vc-hooks.el
+++ b/lisp/vc/vc-hooks.el
@@ -865,6 +865,9 @@ vc-prefix-map
   (let ((map (make-sparse-keymap)))
     (define-key map "a" #'vc-update-change-log)
     (define-key map "b" #'vc-switch-backend)
+    (define-key map "Bc" #'vc-create-tag)
+    (define-key map "Bl" #'vc-print-branch-log)
+    (define-key map "Bs" #'vc-retrieve-tag)
     (define-key map "d" #'vc-dir)
     (define-key map "g" #'vc-annotate)
     (define-key map "G" #'vc-ignore)
@@ -879,6 +882,7 @@ vc-prefix-map
     (define-key map "m" #'vc-merge)
     (define-key map "r" #'vc-retrieve-tag)
     (define-key map "s" #'vc-create-tag)
+    (define-key map "S" #'vc-log-search)
     (define-key map "u" #'vc-revert)
     (define-key map "v" #'vc-next-action)
     (define-key map "+" #'vc-update)

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

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

>> Then it would be only on `B c' in vc-dir-mode?  `C-x v s' isn't very
>> mnemonic, but would removing it from global map inconvenience people?
>> (I've never used it myself.)
>
> Indeed, it seems there is no way to remove old keybindings, especially
> by rebinding them to other commands, so I propose to add new keybindings:

We do remove old keybindings if we think that makes sense.  Like I said,
I've never used that command myself, ever, so I was wondering whether
that was generally the case.  If we believe that it's a rarely used
binding, then we could indeed remove it (or use it for something else).

(Especially since it seems quite un-mnemonic currently.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Juri Linkov]

>>> Then it would be only on `B c' in vc-dir-mode?  `C-x v s' isn't very
>>> mnemonic, but would removing it from global map inconvenience people?
>>> (I've never used it myself.)
>>
>> Indeed, it seems there is no way to remove old keybindings, especially
>> by rebinding them to other commands, so I propose to add new keybindings:
>
> We do remove old keybindings if we think that makes sense.  Like I said,
> I've never used that command myself, ever, so I was wondering whether
> that was generally the case.  If we believe that it's a rarely used
> binding, then we could indeed remove it (or use it for something else).
>
> (Especially since it seems quite un-mnemonic currently.)

I don't know, if someone types a familiar key and it does
something completely different...

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

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> I don't know, if someone types a familiar key and it does
> something completely different...

Yeah, I didn't mean rebind it immediately -- we can remove the binding
now, and then reuse the binding in a couple of releases.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Dmitry Gutov]

On 07.09.2021 18:05, Lars Ingebrigtsen wrote:
> Juri Linkov<juri@linkov.net>  writes:
> 
>> I don't know, if someone types a familiar key and it does
>> something completely different...

As long as it doesn't do anything dangerous right away, that could fly. 
Of course, people can still complain. Depends on how popular it is.

> Yeah, I didn't mean rebind it immediately -- we can remove the binding
> now, and then reuse the binding in a couple of releases.

Speaking of (re)moving bindings: 'C-x v b' (vc-switch-backend) seems 
particularly useless. If it weren't there, the newly added branch 
commands could use the nicer prefix instead of 'C-x v B'. branch-map in 
vc-dir could also be changed to use 'b' (not sure why 'B' was chosen 
there originally: there is no conflict).

Maybe vc-switch-backend sees some occasional use, but moving it to 
something like 'C-x v B' would be more appropriate. Or some other 
longer/complex sequence.

If we do this the conservative way, though, the whole procedure can span 
half a decade:

- Move vc-switch-backend to 'C-x v B' (Emacs 28)
- Move branch-map to 'b' and vc-create-tag to 'C-x v b c' (Emacs 29)
- Finally move vc-search-log to 'C-x v s' (Emacs 30)

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

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Speaking of (re)moving bindings: 'C-x v b' (vc-switch-backend) seems
> particularly useless.

Oh, wow.  What's the use case for that command?  I can't imagine when
that would actually do something useful...  And it's a really old
command, too -- perhaps this was something that made sense in an RCS
world?

> If we do this the conservative way, though, the whole procedure can
> span half a decade:
>
> - Move vc-switch-backend to 'C-x v B' (Emacs 28)
> - Move branch-map to 'b' and vc-create-tag to 'C-x v b c' (Emacs 29)
> - Finally move vc-search-log to 'C-x v s' (Emacs 30)

We could do the first two steps in Emacs 28, perhaps -- if anybody's
actually using `C-x v b', they'll then get

C-x v b-

in the echo area, which should tell them that something's different is
happening now...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Dmitry Gutov]

On 08.09.2021 11:00, Lars Ingebrigtsen wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>> Speaking of (re)moving bindings: 'C-x v b' (vc-switch-backend) seems
>> particularly useless.
> 
> Oh, wow.  What's the use case for that command?  I can't imagine when
> that would actually do something useful...  And it's a really old
> command, too -- perhaps this was something that made sense in an RCS
> world?

I think it's for the case of nested repositories, like in bug#42966 and 
other linked reports. And perhaps our detection might make the wrong 
choice, thus it can be tweaked manually.

I don't have any specific scenario in mind, though. Or personal 
experience with such nesting.

>> If we do this the conservative way, though, the whole procedure can
>> span half a decade:
>>
>> - Move vc-switch-backend to 'C-x v B' (Emacs 28)
>> - Move branch-map to 'b' and vc-create-tag to 'C-x v b c' (Emacs 29)
>> - Finally move vc-search-log to 'C-x v s' (Emacs 30)
> 
> We could do the first two steps in Emacs 28, perhaps -- if anybody's
> actually using `C-x v b', they'll then get
> 
> C-x v b-
> 
> in the echo area, which should tell them that something's different is
> happening now...

Works for me.

Juri, what do you say?

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

[Juri Linkov]

>>> Speaking of (re)moving bindings: 'C-x v b' (vc-switch-backend) seems
>>> particularly useless.
>> Oh, wow.  What's the use case for that command?  I can't imagine when
>> that would actually do something useful...  And it's a really old
>> command, too -- perhaps this was something that made sense in an RCS
>> world?
>
> I think it's for the case of nested repositories, like in bug#42966 and
> other linked reports. And perhaps our detection might make the wrong
> choice, thus it can be tweaked manually.
>
> I don't have any specific scenario in mind, though. Or personal experience
> with such nesting.
>
>>> If we do this the conservative way, though, the whole procedure can
>>> span half a decade:
>>>
>>> - Move vc-switch-backend to 'C-x v B' (Emacs 28)
>>> - Move branch-map to 'b' and vc-create-tag to 'C-x v b c' (Emacs 29)
>>> - Finally move vc-search-log to 'C-x v s' (Emacs 30)
>> We could do the first two steps in Emacs 28, perhaps -- if anybody's
>> actually using `C-x v b', they'll then get
>> C-x v b-
>> in the echo area, which should tell them that something's different is
>> happening now...
>
> Works for me.
>
> Juri, what do you say?

I think in the long-term it would be nice to have these keybindings:

C-x v B   - vc-switch-backend
C-x v b c - vc-create-tag (maybe it should have an alias 'vc-create-branch'?)
C-x v b l - vc-print-branch-log
C-x v b s - vc-retrieve-tag (maybe it should have an alias 'vc-switch-branch'?)
C-x v s   - vc-log-search
C-x v r   - free, any ideas what to bind to it?

Since `C-x v b' will show "C-x v b-" in the echo area,
and `C-x v s' will show "Search log with pattern: " in the minibuffer.
and `C-x v r' will show "C-x v r is undefined",
I see no problem in adding all keybindings before the next release.

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

[Dmitry Gutov]

On 09.09.2021 20:39, Juri Linkov wrote:

>> Juri, what do you say?
> 
> I think in the long-term it would be nice to have these keybindings:
> 
> C-x v B   - vc-switch-backend
> C-x v b c - vc-create-tag (maybe it should have an alias 'vc-create-branch'?)
> C-x v b l - vc-print-branch-log
> C-x v b s - vc-retrieve-tag (maybe it should have an alias 'vc-switch-branch'?)
> C-x v s   - vc-log-search
> C-x v r   - free, any ideas what to bind to it?

vc-rename-file, perhaps?

> Since `C-x v b' will show "C-x v b-" in the echo area,
> and `C-x v s' will show "Search log with pattern: " in the minibuffer.
> and `C-x v r' will show "C-x v r is undefined",
> I see no problem in adding all keybindings before the next release.

It's a bit too optimistic even for me. But no objections, really.

I'd like to leave it up to Lars to choose the exact line between being 
conservative and bringing better bindings to the users sooner.

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

[Juri Linkov]

>> C-x v B   - vc-switch-backend
>> C-x v b c - vc-create-tag (maybe it should have an alias 'vc-create-branch'?)
>> C-x v b l - vc-print-branch-log
>> C-x v b s - vc-retrieve-tag (maybe it should have an alias 'vc-switch-branch'?)
>> C-x v s   - vc-log-search
>> C-x v r   - free, any ideas what to bind to it?
>
> vc-rename-file, perhaps?

Or use it as a prefix key to allow more keybindings, e.g.
with mnemonics "revision" to navigate the history like
in vc-annotate: 'C-x v r n' (revision-next), 'C-x v r p' (previous), ...

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

[Dmitry Gutov]

On 10.09.2021 09:46, Juri Linkov wrote:
>>> C-x v B   - vc-switch-backend
>>> C-x v b c - vc-create-tag (maybe it should have an alias 'vc-create-branch'?)
>>> C-x v b l - vc-print-branch-log
>>> C-x v b s - vc-retrieve-tag (maybe it should have an alias 'vc-switch-branch'?)
>>> C-x v s   - vc-log-search
>>> C-x v r   - free, any ideas what to bind to it?
>> vc-rename-file, perhaps?
> Or use it as a prefix key to allow more keybindings, e.g.
> with mnemonics "revision" to navigate the history like
> in vc-annotate: 'C-x v r n' (revision-next), 'C-x v r p' (previous), ...

Do you have some particular commands in mind?

In general, when we check out a file at a different revision, revision's 
name is appended to the file name. So the same kind of iteration as with 
vc-annotate will not work.

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

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> I think in the long-term it would be nice to have these keybindings:
>
> C-x v B   - vc-switch-backend
> C-x v b c - vc-create-tag (maybe it should have an alias 'vc-create-branch'?)
> C-x v b l - vc-print-branch-log
> C-x v b s - vc-retrieve-tag (maybe it should have an alias 'vc-switch-branch'?)
> C-x v s   - vc-log-search
> C-x v r   - free, any ideas what to bind to it?
>
> Since `C-x v b' will show "C-x v b-" in the echo area,
> and `C-x v s' will show "Search log with pattern: " in the minibuffer.
> and `C-x v r' will show "C-x v r is undefined",
> I see no problem in adding all keybindings before the next release.

It's an ambitious rebinding...  but the new bindings are clearly an
improvement, and none of the commands that are being rebound to/from are
things that "do things immediately", but instead prompt for further
input, so the potential for this to destroy people's repositories should be
lessened.

But...  perhaps we should take this to emacs-devel to see whether other
people feel differently?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Dmitry Gutov]

On 10.09.2021 13:32, Lars Ingebrigtsen wrote:
> But...  perhaps we should take this to emacs-devel to see whether other
> people feel differently?

Some people might feel the desire to express general objection to seeing 
anything changed.

But sure.

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

[Juri Linkov]

>> But...  perhaps we should take this to emacs-devel to see whether other
>> people feel differently?
>
> Some people might feel the desire to express general objection to seeing
> anything changed.

I realized that quite likely many users already rely on 'C-x v s'
and 'C-x v r' to create/switch branches because currently there is
no other quick way to do these frequent actions.  OTOH, I don't
believe that 'vc-switch-backend' is used often.  So it seems pretty safe
to just create a new prefix key map for 'C-x v b', and rebind 'vc-switch-backend'
to 'C-x v B'.  Then leave 'C-x v r' and 'C-x v s' unchanged to give
users time to adopt to the new branch-related prefix map 'C-x v b'.

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

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 1104 bytes --]

> I realized that quite likely many users already rely on 'C-x v s'
> and 'C-x v r' to create/switch branches because currently there is
> no other quick way to do these frequent actions.  OTOH, I don't
> believe that 'vc-switch-backend' is used often.  So it seems pretty safe
> to just create a new prefix key map for 'C-x v b', and rebind 'vc-switch-backend'
> to 'C-x v B'.  Then leave 'C-x v r' and 'C-x v s' unchanged to give
> users time to adopt to the new branch-related prefix map 'C-x v b'.

It will take more time to create branch commands due to many problems.
So the best what we could do now is to rebind 'vc-switch-backend'
from 'C-x v b' to 'C-x v B' in emacs-28 to give time to adapt
to  new keybinding.  'vc-switch-backend' was announced in NEWS thusly:

  If a file is registered in multiple backends, you can switch to
  another one using C-x v b (vc-switch-backend).  This does not change
  any files, it only changes VC's perspective on the file.  Use this to
  pick up changes from CVS while working under RCS locally.

So it was intended to switch backends between CVS and RCS.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: vc-switch-backend.patch --]
[-- Type: text/x-diff, Size: 1093 bytes --]

diff --git a/etc/NEWS b/etc/NEWS
index 8b327fac0f..26af52af58 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -3299,6 +3299,10 @@ Setting this to nil inhibits that.
 ** 'vc-print-branch-log' shows the change log from its root directory.
 It previously used to use the default directory.
 
+---
+** 'vc-switch-backend' is rebound from 'C-x v b' to 'C-x v B'.
+The prefix key 'C-x v b' is reserved for coming branch commands.
+
 ---
 ** 'project-shell' and 'shell' now use 'pop-to-buffer-same-window'.
 This is to keep the same behavior as Eshell.
diff --git a/lisp/vc/vc-hooks.el b/lisp/vc/vc-hooks.el
index b7760e3bba..7455a306bc 100644
--- a/lisp/vc/vc-hooks.el
+++ b/lisp/vc/vc-hooks.el
@@ -864,7 +864,8 @@ vc-kill-buffer-hook
 (defvar vc-prefix-map
   (let ((map (make-sparse-keymap)))
     (define-key map "a" #'vc-update-change-log)
-    (define-key map "b" #'vc-switch-backend)
+    ;; TODO: Use the prefix key "b" for branch commands.
+    (define-key map "B" #'vc-switch-backend)
     (define-key map "d" #'vc-dir)
     (define-key map "g" #'vc-annotate)
     (define-key map "G" #'vc-ignore)

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

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Thu, 07 Oct 2021 10:21:45 +0300
> Cc: 50344@debbugs.gnu.org, Lars Ingebrigtsen <larsi@gnus.org>
> 
> It will take more time to create branch commands due to many problems.
> So the best what we could do now is to rebind 'vc-switch-backend'
> from 'C-x v b' to 'C-x v B' in emacs-28 to give time to adapt
> to  new keybinding.

Please don't change such old key bindings, not unless we are
deprecating the command (which we aren't, AFAIU).

>'vc-switch-backend' was announced in NEWS thusly:
> 
>   If a file is registered in multiple backends, you can switch to
>   another one using C-x v b (vc-switch-backend).  This does not change
>   any files, it only changes VC's perspective on the file.  Use this to
>   pick up changes from CVS while working under RCS locally.
> 
> So it was intended to switch backends between CVS and RCS.

It was then, but it can be used today with other backends.

So I'm opposed to such a change.  (And it's too late for incompatible
changes on the emacs-28 branch anyway.)

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

[Juri Linkov]

>> It will take more time to create branch commands due to many problems.
>> So the best what we could do now is to rebind 'vc-switch-backend'
>> from 'C-x v b' to 'C-x v B' in emacs-28 to give time to adapt
>> to  new keybinding.
>
> Please don't change such old key bindings, not unless we are
> deprecating the command (which we aren't, AFAIU).

Sorry, I see no connection: why changing key bindings requires
deprecating the command?

>>'vc-switch-backend' was announced in NEWS thusly:
>>
>>   If a file is registered in multiple backends, you can switch to
>>   another one using C-x v b (vc-switch-backend).  This does not change
>>   any files, it only changes VC's perspective on the file.  Use this to
>>   pick up changes from CVS while working under RCS locally.
>>
>> So it was intended to switch backends between CVS and RCS.
>
> It was then, but it can be used today with other backends.

What backends do you switch with 'C-x v b' today?

> So I'm opposed to such a change.  (And it's too late for incompatible
> changes on the emacs-28 branch anyway.)

It makes no sense to develop branch commands without 'C-x v b' binding.

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

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: dgutov@yandex.ru,  50344@debbugs.gnu.org,  larsi@gnus.org
> Date: Thu, 07 Oct 2021 10:58:10 +0300
> 
> >> It will take more time to create branch commands due to many problems.
> >> So the best what we could do now is to rebind 'vc-switch-backend'
> >> from 'C-x v b' to 'C-x v B' in emacs-28 to give time to adapt
> >> to  new keybinding.
> >
> > Please don't change such old key bindings, not unless we are
> > deprecating the command (which we aren't, AFAIU).
> 
> Sorry, I see no connection: why changing key bindings requires
> deprecating the command?

Because people will expect the old binding to work as long as the
command is useful.

> > It was then, but it can be used today with other backends.
> 
> What backends do you switch with 'C-x v b' today?

You mean, I personally?  Why is that relevant?  If you want to say
that no one uses this command anymore, then that points to deprecating
the command, and when it's obsolete for long enough time (at least one
major release, IMO), we can remove its binding.

> > So I'm opposed to such a change.  (And it's too late for incompatible
> > changes on the emacs-28 branch anyway.)
> 
> It makes no sense to develop branch commands without 'C-x v b' binding.

I don't see why it must end with 'b' to make any sense.  I think you
are exaggerating.

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

[Dmitry Gutov]

On 07.10.2021 11:28, Eli Zaretskii wrote:
>> From: Juri Linkov <juri@linkov.net>
>> Cc: dgutov@yandex.ru,  50344@debbugs.gnu.org,  larsi@gnus.org
>> Date: Thu, 07 Oct 2021 10:58:10 +0300
>>
>>>> It will take more time to create branch commands due to many problems.
>>>> So the best what we could do now is to rebind 'vc-switch-backend'
>>>> from 'C-x v b' to 'C-x v B' in emacs-28 to give time to adapt
>>>> to  new keybinding.
>>>
>>> Please don't change such old key bindings, not unless we are
>>> deprecating the command (which we aren't, AFAIU).
>>
>> Sorry, I see no connection: why changing key bindings requires
>> deprecating the command?
> 
> Because people will expect the old binding to work as long as the
> command is useful.

They shouldn't: we have a lot of commands without dedicated bindings.

This command will retain some marginal utility, for some users out there 
(though I don't know who or why), so removing it doesn't make sense.

But its utility is incommeasurable with the binding it's taking up.

Let's announce in Emacs 28's NEWS that we intend to remove (or take 
away) the binding 'C-x v b'. Just like we did with the TAB binding in 
*xref* buffers.

>>> It was then, but it can be used today with other backends.
>>
>> What backends do you switch with 'C-x v b' today?
> 
> You mean, I personally?  Why is that relevant?  If you want to say
> that no one uses this command anymore, then that points to deprecating
> the command, and when it's obsolete for long enough time (at least one
> major release, IMO), we can remove its binding.

"No one" is a very strong criterion.

What if 2 people total, out of all users, were using this command?

Would you still deprecate it, with intent to remove? Or would you still 
keep the binding?

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

[Eli Zaretskii]

> Cc: 50344@debbugs.gnu.org, larsi@gnus.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 7 Oct 2021 14:12:06 +0300
> 
> >> Sorry, I see no connection: why changing key bindings requires
> >> deprecating the command?
> > 
> > Because people will expect the old binding to work as long as the
> > command is useful.
> 
> They shouldn't: we have a lot of commands without dedicated bindings.
> 
> This command will retain some marginal utility, for some users out there 
> (though I don't know who or why), so removing it doesn't make sense.
> 
> But its utility is incommeasurable with the binding it's taking up.
> 
> Let's announce in Emacs 28's NEWS that we intend to remove (or take 
> away) the binding 'C-x v b'. Just like we did with the TAB binding in 
> *xref* buffers.
> 
> >>> It was then, but it can be used today with other backends.
> >>
> >> What backends do you switch with 'C-x v b' today?
> > 
> > You mean, I personally?  Why is that relevant?  If you want to say
> > that no one uses this command anymore, then that points to deprecating
> > the command, and when it's obsolete for long enough time (at least one
> > major release, IMO), we can remove its binding.
> 
> "No one" is a very strong criterion.
> 
> What if 2 people total, out of all users, were using this command?

That's the same as "no one", for the purposes of this discussion.

> Would you still deprecate it, with intent to remove? Or would you still 
> keep the binding?

I didn't say I was against deprecating the command.  I said
deprecating it is the only way to eventually usurp its key binding.

But deprecation will take time, and I was under the impression that
Juri wanted the VC branch commands to have the binding NOW.

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

[Dmitry Gutov]

On 07.10.2021 15:56, Eli Zaretskii wrote:

>> What if 2 people total, out of all users, were using this command?
> 
> That's the same as "no one", for the purposes of this discussion.

If the command is still useful to a handful of people (some subset of 
CVS/RSC users, apparently), and it doesn't take effort to maintain it, 
it doesn't seem helpful to deprecate it.

Unlike the key binding.

>> Would you still deprecate it, with intent to remove? Or would you still
>> keep the binding?
> 
> I didn't say I was against deprecating the command.  I said
> deprecating it is the only way to eventually usurp its key binding.

And I questioned this statement.

> But deprecation will take time, and I was under the impression that
> Juri wanted the VC branch commands to have the binding NOW.

As Juri said, the new branch commands are not ready yet.

His patch was to prepare the users to this prefix being used for branch 
commands in the next Emacs version. You didn't like the proposed method, 
that's okay.

Let's deprecate the binding in Emacs 28, so it can be used for branch 
commands in Emacs 29.

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

[Eli Zaretskii]

> Cc: juri@linkov.net, 50344@debbugs.gnu.org, larsi@gnus.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 7 Oct 2021 16:06:05 +0300
> 
> Let's deprecate the binding in Emacs 28, so it can be used for branch 
> commands in Emacs 29.

As I already said, I don't want to deprecate the binding if we are not
deprecating the command which uses it.

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

[Dmitry Gutov]

On 07.10.2021 16:21, Eli Zaretskii wrote:
>> Cc:juri@linkov.net,50344@debbugs.gnu.org,larsi@gnus.org
>> From: Dmitry Gutov<dgutov@yandex.ru>
>> Date: Thu, 7 Oct 2021 16:06:05 +0300
>>
>> Let's deprecate the binding in Emacs 28, so it can be used for branch
>> commands in Emacs 29.
> As I already said, I don't want to deprecate the binding if we are not
> deprecating the command which uses it.

Why?

We have commands without bindings.

We didn't deprecate 'xref-quit-and-goto-xref' either.

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

[Eli Zaretskii]

> Cc: juri@linkov.net, 50344@debbugs.gnu.org, larsi@gnus.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 7 Oct 2021 16:26:06 +0300
> 
> On 07.10.2021 16:21, Eli Zaretskii wrote:
> >> Cc:juri@linkov.net,50344@debbugs.gnu.org,larsi@gnus.org
> >> From: Dmitry Gutov<dgutov@yandex.ru>
> >> Date: Thu, 7 Oct 2021 16:06:05 +0300
> >>
> >> Let's deprecate the binding in Emacs 28, so it can be used for branch
> >> commands in Emacs 29.
> > As I already said, I don't want to deprecate the binding if we are not
> > deprecating the command which uses it.
> 
> Why?
> 
> We have commands without bindings.

Because this command _has_ a binding, and had it since Emacs 21.

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

[Juri Linkov]

>> Let's deprecate the binding in Emacs 28, so it can be used for branch 
>> commands in Emacs 29.
>
> As I already said, I don't want to deprecate the binding if we are not
> deprecating the command which uses it.

I don't understand how this is different from removing other keybindings
such as recently removing the global binding 'M-o' ('facemenu-keymap'),
etc.

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

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Dmitry Gutov <dgutov@yandex.ru>,  50344@debbugs.gnu.org,  larsi@gnus.org
> Date: Thu, 07 Oct 2021 20:36:13 +0300
> 
> >> Let's deprecate the binding in Emacs 28, so it can be used for branch 
> >> commands in Emacs 29.
> >
> > As I already said, I don't want to deprecate the binding if we are not
> > deprecating the command which uses it.
> 
> I don't understand how this is different from removing other keybindings
> such as recently removing the global binding 'M-o' ('facemenu-keymap'),
> etc.

It isn't.  But that even was enough pain for a single release, so I'd
like to avoid repeating it.

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

[Dmitry Gutov]

On 07.10.2021 16:21, Eli Zaretskii wrote:
> As I already said, I don't want to deprecate the binding if we are not
> deprecating the command which uses it.

You know what, let's deprecate the command.

This will give us a way to notify its users more prominently, and maybe 
hear back about their patterns.

In Emacs 29, we might as well un-deprecate the command itself but reuse 
its binding for the branch prefix. The deprecation will already have 
done its job. Or, alternatively, nobody will complain, and we could make 
a more informed decision about removing it.

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

[Filipp Gunbin]

On 08/10/2021 00:49 +0300, Dmitry Gutov wrote:

> On 07.10.2021 16:21, Eli Zaretskii wrote:
>> As I already said, I don't want to deprecate the binding if we are not
>> deprecating the command which uses it.
>
> You know what, let's deprecate the command.
>
> This will give us a way to notify its users more prominently, and maybe
> hear back about their patterns.
>
> In Emacs 29, we might as well un-deprecate the command itself but reuse
> its binding for the branch prefix. The deprecation will already have
> done its job. Or, alternatively, nobody will complain, and we could make
> a more informed decision about removing it.

It'd be great to go this way.  C-x v B is perhaps acceptable, but
lowcase b is much, much better.  Enough to sacrifice switching backends
for it IMO.

Filipp

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

[Dmitry Gutov]

On 12.10.2021 15:48, Filipp Gunbin wrote:
> It'd be great to go this way.  C-x v B is perhaps acceptable, but
> lowcase b is much, much better.  Enough to sacrifice switching backends
> for it IMO.

OK, then I guess the follow-up question is, do we obsolete 
'vc-transfer-file' as well? It's the only caller of 'vc-switch-backend' 
outside of interactive invocations.

'vc-transfer-file' can also be used by 'C-u M-x vc-next-action', but it 
seems like a very rare workflow as well. Though more plausible than the 
use of 'vc-switch-backend' by itself.

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

[Filipp Gunbin]

On 13/10/2021 04:45 +0300, Dmitry Gutov wrote:

> On 12.10.2021 15:48, Filipp Gunbin wrote:
>> It'd be great to go this way.  C-x v B is perhaps acceptable, but
>> lowcase b is much, much better.  Enough to sacrifice switching backends
>> for it IMO.
>
> OK, then I guess the follow-up question is, do we obsolete
> 'vc-transfer-file' as well? It's the only caller of 'vc-switch-backend'
> outside of interactive invocations.
>
> 'vc-transfer-file' can also be used by 'C-u M-x vc-next-action', but it
> seems like a very rare workflow as well. Though more plausible than the
> use of 'vc-switch-backend' by itself.

Personally I don't use either of these commands, so this is a question
to others..

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

[Dmitry Gutov]

On 13.10.2021 13:12, Filipp Gunbin wrote:
>> OK, then I guess the follow-up question is, do we obsolete
>> 'vc-transfer-file' as well? It's the only caller of 'vc-switch-backend'
>> outside of interactive invocations.
>>
>> 'vc-transfer-file' can also be used by 'C-u M-x vc-next-action', but it
>> seems like a very rare workflow as well. Though more plausible than the
>> use of 'vc-switch-backend' by itself.
> Personally I don't use either of these commands, so this is a question
> to others..

I guess there's little point to be too ambitious here, given that 
vc-transfer-file is not interactive, and changing vc-next-action's 
signature is not in the cards now anyway.

And we don't have an actual mechanism for obsoleting only a part of 
command's calling convention.

I have pushed the change which obsoletes vc-switch-backend now.

Which should remove the main obstacle to adding the branches map with 
good binding in Emacs 29.

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

[Philip Kaludercic]

Dmitry Gutov <dgutov@yandex.ru> writes:

> I have pushed the change which obsoletes vc-switch-backend now.

So what is the preferred way for switching to another vc backend from
28.1 onward?

-- 
	Philip Kaludercic

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

[Dmitry Gutov]

On 24.12.2021 14:56, Philip Kaludercic wrote:
> Dmitry Gutov<dgutov@yandex.ru>  writes:
> 
>> I have pushed the change which obsoletes vc-switch-backend now.
> So what is the preferred way for switching to another vc backend from
> 28.1 onward?

I suppose it depends on your scenario.

Do you routinely use two different backends in certain projects/directories?

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

[Philip Kaludercic]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 24.12.2021 14:56, Philip Kaludercic wrote:
>> Dmitry Gutov<dgutov@yandex.ru>  writes:
>> 
>>> I have pushed the change which obsoletes vc-switch-backend now.
>> So what is the preferred way for switching to another vc backend from
>> 28.1 onward?
>
> I suppose it depends on your scenario.
>
> Do you routinely use two different backends in certain
> projects/directories?

Yes, when switching between some default vc backend such as git and
vc-backup (from ELPA) to work with backup files.

-- 
	Philip Kaludercic

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

[Dmitry Gutov]

On 24.12.2021 16:57, Philip Kaludercic wrote:
> Dmitry Gutov<dgutov@yandex.ru>  writes:
> 
>> On 24.12.2021 14:56, Philip Kaludercic wrote:
>>> Dmitry Gutov<dgutov@yandex.ru>   writes:
>>>
>>>> I have pushed the change which obsoletes vc-switch-backend now.
>>> So what is the preferred way for switching to another vc backend from
>>> 28.1 onward?
>> I suppose it depends on your scenario.
>>
>> Do you routinely use two different backends in certain
>> projects/directories?
> Yes, when switching between some default vc backend such as git and
> vc-backup (from ELPA) to work with backup files.

I haven't tried that package, but it's a little surprising that 
vc-backup needs such a feature to be fully usable. I guess one option 
would be for it to provide user commands, one of which which would move 
it at the front of vc-handled-backends? An the other would undo that 
action. Or just bundle a copy of vc-switch-backend under a different name.

But if you don't like both of those suggestions, my preferred plan would 
be for you to continue using vc-switch-backend in Emacs 28. In Emacs 29, 
we could un-obsolete it but put it on a different key binding (such as 
'C-x v B'), freeing 'C-x v b' for the prefix map for branch operations.

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

[Philip Kaludercic]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 24.12.2021 16:57, Philip Kaludercic wrote:
>> Dmitry Gutov<dgutov@yandex.ru>  writes:
>> 
>>> On 24.12.2021 14:56, Philip Kaludercic wrote:
>>>> Dmitry Gutov<dgutov@yandex.ru>   writes:
>>>>
>>>>> I have pushed the change which obsoletes vc-switch-backend now.
>>>> So what is the preferred way for switching to another vc backend from
>>>> 28.1 onward?
>>> I suppose it depends on your scenario.
>>>
>>> Do you routinely use two different backends in certain
>>> projects/directories?
>> Yes, when switching between some default vc backend such as git and
>> vc-backup (from ELPA) to work with backup files.
>
> I haven't tried that package, but it's a little surprising that
> vc-backup needs such a feature to be fully usable. I guess one option
> would be for it to provide user commands, one of which which would
> move it at the front of vc-handled-backends? An the other would undo
> that action. Or just bundle a copy of vc-switch-backend under a
> different name.

The package is still usable, you just don't get to work on backups when
your file is managed by some other version control system (unless you
want prioritise it over any other backend).  If it is the case, that
vc-switch-backend is rarely used, it seems like adding a custom
vc-backup-toggle-backend command to vc-backup would make the most sense.

> But if you don't like both of those suggestions, my preferred plan
> would be for you to continue using vc-switch-backend in Emacs 28. In
> Emacs 29, we could un-obsolete it but put it on a different key
> binding (such as 'C-x v B'), freeing 'C-x v b' for the prefix map for
> branch operations.

Maybe I missed something, but would the issue be to just unbind the key,
without obsoleting it?  FWIW I would also appreciate having C-x v b
bound to branch commands.

-- 
	Philip Kaludercic

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

[Dmitry Gutov]

On 25.12.2021 14:37, Philip Kaludercic wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>> On 24.12.2021 16:57, Philip Kaludercic wrote:
>>> Dmitry Gutov<dgutov@yandex.ru>  writes:
>>>
>>>> On 24.12.2021 14:56, Philip Kaludercic wrote:
>>>>> Dmitry Gutov<dgutov@yandex.ru>   writes:
>>>>>
>>>>>> I have pushed the change which obsoletes vc-switch-backend now.
>>>>> So what is the preferred way for switching to another vc backend from
>>>>> 28.1 onward?
>>>> I suppose it depends on your scenario.
>>>>
>>>> Do you routinely use two different backends in certain
>>>> projects/directories?
>>> Yes, when switching between some default vc backend such as git and
>>> vc-backup (from ELPA) to work with backup files.
>>
>> I haven't tried that package, but it's a little surprising that
>> vc-backup needs such a feature to be fully usable. I guess one option
>> would be for it to provide user commands, one of which which would
>> move it at the front of vc-handled-backends? An the other would undo
>> that action. Or just bundle a copy of vc-switch-backend under a
>> different name.
> 
> The package is still usable, you just don't get to work on backups when
> your file is managed by some other version control system (unless you
> want prioritise it over any other backend).  If it is the case, that
> vc-switch-backend is rarely used, it seems like adding a custom
> vc-backup-toggle-backend command to vc-backup would make the most sense.

Yes, we all thought it is rarely used.

>> But if you don't like both of those suggestions, my preferred plan
>> would be for you to continue using vc-switch-backend in Emacs 28. In
>> Emacs 29, we could un-obsolete it but put it on a different key
>> binding (such as 'C-x v B'), freeing 'C-x v b' for the prefix map for
>> branch operations.
> 
> Maybe I missed something, but would the issue be to just unbind the key,
> without obsoleting it?  FWIW I would also appreciate having C-x v b
> bound to branch commands.

You missed a bunch of comments in this bug discussion.

Unbinding without obsoleting makes sense to me, but not to Eli.

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

[Sean Whitton]

Hello,

On Thu 14 Oct 2021 at 02:37AM +03, Dmitry Gutov wrote:

> I have pushed the change which obsoletes vc-switch-backend now.
>
> Which should remove the main obstacle to adding the branches map with good
> binding in Emacs 29.

Would now perhaps be an appropriate time to go ahead and add the
branches map?

-- 
Sean Whitton

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

[Juri Linkov]

>> I have pushed the change which obsoletes vc-switch-backend now.
>>
>> Which should remove the main obstacle to adding the branches map with good
>> binding in Emacs 29.
>
> Would now perhaps be an appropriate time to go ahead and add the
> branches map?

Agreed.  I could try to prepare a complete patch tomorrow.

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

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> Agreed.  I could try to prepare a complete patch tomorrow.

Sounds good.

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

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 350 bytes --]

>> I have pushed the change which obsoletes vc-switch-backend now.
>>
>> Which should remove the main obstacle to adding the branches map with good
>> binding in Emacs 29.
>
> Would now perhaps be an appropriate time to go ahead and add the
> branches map?

Here is the complete patch that addresses all concerns
raised during this long discussion:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: vc-create-branch.patch --]
[-- Type: text/x-diff, Size: 8047 bytes --]

diff --git a/lisp/vc/vc.el b/lisp/vc/vc.el
index c4f0671d64..a9627a2862 100644
--- a/lisp/vc/vc.el
+++ b/lisp/vc/vc.el
@@ -449,7 +449,7 @@
 ;;
 ;;   Return the common ancestor between REV1 and REV2 revisions.
 
-;; TAG SYSTEM
+;; TAG/BRANCH SYSTEM
 ;;
 ;; - create-tag (dir name branchp)
 ;;
@@ -464,8 +464,9 @@
 ;; - retrieve-tag (dir name update)
 ;;
 ;;   Retrieve the version tagged by NAME of all registered files at or below DIR.
+;;   If NAME is a branch name, switch to that branch.
 ;;   If UPDATE is non-nil, then update buffers of any files in the
-;;   tag that are currently visited.  The default implementation
+;;   tag/branch that are currently visited.  The default implementation
 ;;   does a sanity check whether there aren't any uncommitted changes at
 ;;   or below DIR, and then performs a tree walk, using the `checkout'
 ;;   function to retrieve the corresponding revisions.
@@ -664,8 +665,6 @@
 ;;   display the branch name in the mode-line.  Replace
 ;;   vc-cvs-sticky-tag with that.
 ;;
-;; - Add a primitives for switching to a branch (creating it if required.
-;;
 ;; - Add the ability to list tags and branches.
 ;;
 ;;;; Unify two different versions of the amend capability
@@ -2432,7 +2431,23 @@ vc-create-tag
   (message "Making %s... done" (if branchp "branch" "tag")))
 
 ;;;###autoload
-(defun vc-retrieve-tag (dir name)
+(defun vc-create-branch (dir name)
+  "Descending recursively from DIR, make a branch called NAME.
+After a new branch is made, the files are checked out in that new branch.
+Uses `vc-create-tag' with the non-nil arg `branchp'."
+  (interactive
+   (let ((granularity
+          (vc-call-backend (vc-responsible-backend default-directory)
+                           'revision-granularity)))
+     (list
+      (if (eq granularity 'repository)
+          default-directory
+        (read-directory-name "Directory: " default-directory default-directory t))
+      (read-string "New branch name: " nil 'vc-revision-history))))
+  (vc-create-tag dir name t))
+
+;;;###autoload
+(defun vc-retrieve-tag (dir name &optional branchp)
   "For each file in or below DIR, retrieve their tagged version NAME.
 NAME can name a branch, in which case this command will switch to the
 named branch in the directory DIR.
@@ -2442,6 +2457,8 @@ vc-retrieve-tag
 If locking is used for the files in DIR, then there must not be any
 locked files at or below DIR (but if NAME is empty, locked files are
 allowed and simply skipped).
+If the prefix argument BRANCHP is given, switch the branch
+and check out the files in that branch.
 This function runs the hook `vc-retrieve-tag-hook' when finished."
   (interactive
    (let* ((granularity
@@ -2457,15 +2474,21 @@ vc-retrieve-tag
              (read-directory-name "Directory: " default-directory nil t))))
      (list
       dir
-      (vc-read-revision (format-prompt "Tag name to retrieve" "latest revisions")
+      (vc-read-revision (format-prompt
+                         (if current-prefix-arg
+                             "Switch to branch"
+                           "Tag name to retrieve")
+                         "latest revisions")
                         (list dir)
-                        (vc-responsible-backend dir)))))
+                        (vc-responsible-backend dir))
+      current-prefix-arg)))
   (let* ((backend (vc-responsible-backend dir))
          (update (when (vc-call-backend backend 'update-on-retrieve-tag)
                    (yes-or-no-p "Update any affected buffers? ")))
 	 (msg (if (or (not name) (string= name ""))
 		  (format "Updating %s... " (abbreviate-file-name dir))
-	        (format "Retrieving tag %s into %s... "
+	        (format "Retrieving %s %s into %s... "
+                        (if branchp "branch" "tag")
 		        name (abbreviate-file-name dir)))))
     (message "%s" msg)
     (vc-call-backend backend 'retrieve-tag dir name update)
@@ -2473,6 +2496,25 @@ vc-retrieve-tag
     (run-hooks 'vc-retrieve-tag-hook)
     (message "%s" (concat msg "done"))))
 
+;;;###autoload
+(defun vc-switch-branch (dir name)
+  "Switch to the branch NAME in the directory DIR.
+If NAME is empty, it refers to the latest revisions of the current branch.
+Uses `vc-retrieve-tag' with the non-nil arg `branchp'."
+  (interactive
+   (let* ((granularity
+           (vc-call-backend (vc-responsible-backend default-directory)
+                            'revision-granularity))
+          (dir
+           (if (eq granularity 'repository)
+               (expand-file-name (vc-root-dir))
+             (read-directory-name "Directory: " default-directory nil t))))
+     (list
+      dir
+      (vc-read-revision (format-prompt "Switch to branch" "latest revisions")
+                        (list dir)
+                        (vc-responsible-backend dir)))))
+  (vc-retrieve-tag dir name t))
 
 ;; Miscellaneous other entry points
 
diff --git a/lisp/vc/vc-git.el b/lisp/vc/vc-git.el
index 2941cc75be..792981b142 100644
--- a/lisp/vc/vc-git.el
+++ b/lisp/vc/vc-git.el
@@ -82,7 +82,7 @@
 ;; - annotate-time ()                              OK
 ;; - annotate-current-time ()                      NOT NEEDED
 ;; - annotate-extract-revision-at-line ()          OK
-;; TAG SYSTEM
+;; TAG/BRANCH SYSTEM
 ;; - create-tag (dir name branchp)                 OK
 ;; - retrieve-tag (dir name update)                OK
 ;; MISCELLANEOUS
@@ -1572,13 +1590,25 @@ vc-git-annotate-extract-revision-at-line
 		    (expand-file-name fname (vc-git-root default-directory))))
 	  revision)))))
 
-;;; TAG SYSTEM
+;;; TAG/BRANCH SYSTEM
+
+(declare-function vc-read-revision "vc"
+                  (prompt &optional files backend default initial-input))
 
 (defun vc-git-create-tag (dir name branchp)
-  (let ((default-directory dir))
-    (and (vc-git-command nil 0 nil "update-index" "--refresh")
+  (let ((default-directory dir)
+        (start-point (when branchp (vc-read-revision
+                                    (format-prompt "Start point"
+                                                   (car (vc-git-branches)))
+                                    (list dir) 'Git))))
+    (and (or (zerop (vc-git-command nil t nil "update-index" "--refresh"))
+             (y-or-n-p "Modified files exist.  Proceed? ")
+             (user-error (format "Can't create %s with modified files"
+                                 (if branchp "branch" "tag"))))
          (if branchp
-             (vc-git-command nil 0 nil "checkout" "-b" name)
+             (vc-git-command nil 0 nil "checkout" "-b" name
+                             (when (and start-point (not (eq start-point "")))
+                               start-point))
            (vc-git-command nil 0 nil "tag" name)))))
 
 (defun vc-git-retrieve-tag (dir name _update)
diff --git a/lisp/vc/vc-hooks.el b/lisp/vc/vc-hooks.el
index 1f0eeb7e18..8f9e6010ee 100644
--- a/lisp/vc/vc-hooks.el
+++ b/lisp/vc/vc-hooks.el
@@ -857,6 +857,9 @@ vc-kill-buffer-hook
 ;; (autoload 'vc-prefix-map "vc" nil nil 'keymap)
 (defvar-keymap vc-prefix-map
   "a"   #'vc-update-change-log
+  "b c" #'vc-create-branch
+  "b l" #'vc-print-branch-log
+  "b s" #'vc-switch-branch
   "d"   #'vc-dir
   "g"   #'vc-annotate
   "G"   #'vc-ignore
@@ -883,9 +887,6 @@ vc-prefix-map
 (fset 'vc-prefix-map vc-prefix-map)
 (define-key ctl-x-map "v" 'vc-prefix-map)
 
-(with-suppressed-warnings ((obsolete vc-switch-backend))
-  (keymap-set vc-prefix-map "b" #'vc-switch-backend))
-
 (defvar vc-menu-map
   (let ((map (make-sparse-keymap "Version Control")))
     ;;(define-key map [show-files]
diff --git a/lisp/vc/vc-dir.el b/lisp/vc/vc-dir.el
index 068a66b25b..aa8bad7961 100644
--- a/lisp/vc/vc-dir.el
+++ b/lisp/vc/vc-dir.el
@@ -356,7 +356,7 @@ vc-dir-mode-map
     (define-key map "G" #'vc-dir-ignore)
 
     (let ((branch-map (make-sparse-keymap)))
-      (define-key map "B" branch-map)
+      (define-key map "b" branch-map)
       (define-key branch-map "c" #'vc-create-tag)
       (define-key branch-map "l" #'vc-print-branch-log)
       (define-key branch-map "s" #'vc-retrieve-tag))

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

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> Here is the complete patch that addresses all concerns
> raised during this long discussion:

I have not tested the patch, but it makes sense to me, so feel free to
go ahead and push it (with a NEWS entry).

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

[Juri Linkov]

close 50344 29.0.50
thanks

>> Here is the complete patch that addresses all concerns
>> raised during this long discussion:
>
> I have not tested the patch, but it makes sense to me, so feel free to
> go ahead and push it (with a NEWS entry).

So now pushed with a NEWS entry, and closed.

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

[Eli Zaretskii]

> Cc: 50344@debbugs.gnu.org, Dmitry Gutov <dgutov@yandex.ru>,
>  Filipp Gunbin <fgunbin@fastmail.fm>, Sean Whitton <spwhitton@spwhitton.name>
> From: Juri Linkov <juri@linkov.net>
> Date: Mon, 12 Sep 2022 21:07:50 +0300
> 
> >> Here is the complete patch that addresses all concerns
> >> raised during this long discussion:
> >
> > I have not tested the patch, but it makes sense to me, so feel free to
> > go ahead and push it (with a NEWS entry).
> 
> So now pushed with a NEWS entry, and closed.

Thanks, but what about updating the manual?  Failing to update the
manuals when code changes are installed results in huge backlog of
documentation changes that at best delays release of the future
version, and at worst leaves important features undocumented.

We once had a de-facto rule that manuals should be updated together
with the code.  What happened?

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

[Juri Linkov]

>> > I have not tested the patch, but it makes sense to me, so feel free to
>> > go ahead and push it (with a NEWS entry).
>> 
>> So now pushed with a NEWS entry, and closed.
>
> Thanks, but what about updating the manual?  Failing to update the
> manuals when code changes are installed results in huge backlog of
> documentation changes that at best delays release of the future
> version, and at worst leaves important features undocumented.
>
> We once had a de-facto rule that manuals should be updated together
> with the code.  What happened?

Sorry, I thought that a missing sign "+++" or "---" indicates that
the decision whether and where to document this could be postponed
to a later time.  But now the manual is updated.

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

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: larsi@gnus.org,  50344@debbugs.gnu.org,  dgutov@yandex.ru,
>   fgunbin@fastmail.fm,  spwhitton@spwhitton.name
> Date: Mon, 12 Sep 2022 22:13:20 +0300
> 
> > Thanks, but what about updating the manual?  Failing to update the
> > manuals when code changes are installed results in huge backlog of
> > documentation changes that at best delays release of the future
> > version, and at worst leaves important features undocumented.
> >
> > We once had a de-facto rule that manuals should be updated together
> > with the code.  What happened?
> 
> Sorry, I thought that a missing sign "+++" or "---" indicates that
> the decision whether and where to document this could be postponed
> to a later time.  But now the manual is updated.

Thanks!

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

[Sean Whitton]

Hello,

On Mon 12 Sep 2022 at 09:07PM +03, Juri Linkov wrote:

> close 50344 29.0.50
> thanks
>
>>> Here is the complete patch that addresses all concerns
>>> raised during this long discussion:
>>
>> I have not tested the patch, but it makes sense to me, so feel free to
>> go ahead and push it (with a NEWS entry).
>
> So now pushed with a NEWS entry, and closed.

Thank you!

-- 
Sean Whitton

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

[Robert Pluim]

>>>>> On Thu, 07 Oct 2021 15:56:30 +0300, Eli Zaretskii <eliz@gnu.org> said:

    Eli> That's the same as "no one", for the purposes of this discussion.

    >> Would you still deprecate it, with intent to remove? Or would you still 
    >> keep the binding?

    Eli> I didn't say I was against deprecating the command.  I said
    Eli> deprecating it is the only way to eventually usurp its key binding.

- itʼs undocumented except in NEWS.21
- the workflow itʼs intended for requires you to use the
  (undocumented) prefix arg to 'vc-next-action'
- and that workflow is something that I very much doubt anybody still
  uses (temporarily using RCS for CVS controlled files? Just use git,
  or hg or anything from the last 20 years)

    Eli> But deprecation will take time, and I was under the impression that
    Eli> Juri wanted the VC branch commands to have the binding NOW.

I can see that we want to be careful about deprecation, but this
command is *really* niche. How about we move it to C-x v B, and let
Juri have C-x v b ?

Robert
-- 

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

[Filipp Gunbin]

On 07/10/2021 15:11 +0200, Robert Pluim wrote:

> I can see that we want to be careful about deprecation, but this
> command is *really* niche. How about we move it to C-x v B, and let
> Juri have C-x v b ?

+1

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

[Gregory Heytings]

>
> It makes no sense to develop branch commands without 'C-x v b' binding.
>

If C-x v b isn't available anymore, perhaps C-x v < or ^ would be a good 
alternative?

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

[Dmitry Gutov]

On 07.10.2021 12:57, Gregory Heytings wrote:
>>
>> It makes no sense to develop branch commands without 'C-x v b' binding.
>>
> 
> If C-x v b isn't available anymore, perhaps C-x v < or ^ would be a good 
> alternative?

For vc-switch-backend?

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

[Gregory Heytings]

>>> It makes no sense to develop branch commands without 'C-x v b' 
>>> binding.
>> 
>> If C-x v b isn't available anymore, perhaps C-x v < or ^ would be a 
>> good alternative?
>
> For vc-switch-backend?
>

No, for vc-branch-* commands.  vc-switch-backend is already on C-x v b.

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

[Dmitry Gutov]

On 07.10.2021 14:25, Gregory Heytings wrote:
> 
>>>> It makes no sense to develop branch commands without 'C-x v b' binding.
>>>
>>> If C-x v b isn't available anymore, perhaps C-x v < or ^ would be a 
>>> good alternative?
>>
>> For vc-switch-backend?
>>
> 
> No, for vc-branch-* commands.  vc-switch-backend is already on C-x v b.

It doesn't really make sense to move the branch commands to 'C-x v <' 
while vc-dir-mode-map has branch commands on 'C-x v B'. We should make 
the UI more uniform, not create more exceptions.

It's not mnemonic either.

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

[Gregory Heytings]

>
> It doesn't really make sense to move the branch commands to 'C-x v <' 
> while vc-dir-mode-map has branch commands on 'C-x v B'. We should make 
> the UI more uniform, not create more exceptions.
>

These were my 2 cents, just an idea.

>
> It's not mnemonic either.
>

IMO it is, '<' is a visual representation of two branches.  I wouldn't be 
surprised if '<' was used (as an icon) to open a dialog for branch 
operations in some other editor.

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

[Kévin Le Gouguec]

Gregory Heytings <gregory@heytings.org> writes:

>> It's not mnemonic either.
>>
>
> IMO it is, '<' is a visual representation of two branches.  I wouldn't
> be surprised if '<' was used (as an icon) to open a dialog for branch
> operations in some other editor.

(With apologies for contributing to the bikeshed,)

'y' kinda works too by the same logic, and is unused by vc AFAICT?
Magit uses 'y' for "refs" commands[1], which bring up buffers
enumerating branches and tags).

(Magit does use 'b' for branch management in general though.  IMO it is
more intuitive for a VC system to bind commonly used branch commands[2]
to 'b'; switching backends sounds like a one-off maintenance operation
that one would hopefully not need a dedicated binding for.)


[1] https://magit.vc/manual/magit/References-Buffer.html

[2] Such as those described upthread, e.g. creating branches, showing
    their log, checking them out:

    <878rz72wqg.fsf@mail.linkov.net>
    https://lists.gnu.org/archive/html/bug-gnu-emacs/2021-10/msg00483.html

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

[Filipp Gunbin]

On 07/10/2021 14:35 +0300, Dmitry Gutov wrote:

> On 07.10.2021 14:25, Gregory Heytings wrote:
>>
>>>>> It makes no sense to develop branch commands without 'C-x v b' binding.
>>>>
>>>> If C-x v b isn't available anymore, perhaps C-x v < or ^ would be a
>>>> good alternative?
>>>
>>> For vc-switch-backend?
>>>
>>
>> No, for vc-branch-* commands.  vc-switch-backend is already on C-x v b.
>
> It doesn't really make sense to move the branch commands to 'C-x v <'
> while vc-dir-mode-map has branch commands on 'C-x v B'. We should make
> the UI more uniform, not create more exceptions.
>
> It's not mnemonic either.

Maybe I missing something, but why can't we assign branch commands to
the C-x v B prefix?

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

[Dmitry Gutov]

On 07.10.2021 15:42, Filipp Gunbin wrote:
> Maybe I missing something, but why can't we assign branch commands to
> the C-x v B prefix?

Yeah, we could.

But when someone else comes along and asks why we have everybody 
pressing Shift every time they need to do something with a branch, I 
won't have a good answer.

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

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 7 Oct 2021 14:35:06 +0300
> Cc: 50344@debbugs.gnu.org, larsi@gnus.org, Juri Linkov <juri@linkov.net>
> 
> It doesn't really make sense to move the branch commands to 'C-x v <' 
> while vc-dir-mode-map has branch commands on 'C-x v B'. We should make 
> the UI more uniform, not create more exceptions.

I agree, but then why not use "C-x v B", as was discussed originally?

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

[Eli Zaretskii]

> Date: Thu, 07 Oct 2021 09:57:24 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: Eli Zaretskii <eliz@gnu.org>, 50344@debbugs.gnu.org, larsi@gnus.org, 
>     dgutov@yandex.ru
> 
> If C-x v b isn't available anymore, perhaps C-x v < or ^ would be a good 
> alternative?

Frankly, I don't understand why "C-x v B" suddenly stopped being a
good candidate.  It was discussed at the beginning, but then was
suddenly dropped.  I think it will make a better choice than what you
propose above, because it's somewhat easier to type, especially on
non-US keyboards (I think).

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

[Juri Linkov]

> Frankly, I don't understand why "C-x v B" suddenly stopped being a
> good candidate.  It was discussed at the beginning, but then was
> suddenly dropped.  I think it will make a better choice than what you
> propose above, because it's somewhat easier to type, especially on
> non-US keyboards (I think).

Because for a few days I already tried to use 'C-x v B l' since
I need to check the logs of other branches many times per day,
and it was absolutely horrible experience — Shift+B is very
hard to type because "B" is in the middle of the keyboard,
and after I almost got RSI, I had to rebind it to `C-x v b l'
for the relief.

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

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Gregory Heytings <gregory@heytings.org>,  50344@debbugs.gnu.org,
>   larsi@gnus.org,  dgutov@yandex.ru
> Date: Thu, 07 Oct 2021 20:30:10 +0300
> 
> > Frankly, I don't understand why "C-x v B" suddenly stopped being a
> > good candidate.  It was discussed at the beginning, but then was
> > suddenly dropped.  I think it will make a better choice than what you
> > propose above, because it's somewhat easier to type, especially on
> > non-US keyboards (I think).
> 
> Because for a few days I already tried to use 'C-x v B l' since
> I need to check the logs of other branches many times per day,
> and it was absolutely horrible experience — Shift+B is very
> hard to type because "B" is in the middle of the keyboard,
> and after I almost got RSI, I had to rebind it to `C-x v b l'
> for the relief.

I don't get any trouble pressing this sequence: since Ctrl is already
released, I have that finger to press Shift, which is near Ctrl.

But if most people have the same problematic experience as you did, I
guess we should try looking for another lower-case letter.  Only 13 of
the 26 possible are taken now.

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

[Filipp Gunbin]

On 09/09/2021 20:39 +0300, Juri Linkov wrote:

>>>> Speaking of (re)moving bindings: 'C-x v b' (vc-switch-backend) seems
>>>> particularly useless.
>>> Oh, wow.  What's the use case for that command?  I can't imagine when
>>> that would actually do something useful...  And it's a really old
>>> command, too -- perhaps this was something that made sense in an RCS
>>> world?
>>
>> I think it's for the case of nested repositories, like in bug#42966 and
>> other linked reports. And perhaps our detection might make the wrong
>> choice, thus it can be tweaked manually.
>>
>> I don't have any specific scenario in mind, though. Or personal experience
>> with such nesting.
>>
>>>> If we do this the conservative way, though, the whole procedure can
>>>> span half a decade:
>>>>
>>>> - Move vc-switch-backend to 'C-x v B' (Emacs 28)
>>>> - Move branch-map to 'b' and vc-create-tag to 'C-x v b c' (Emacs 29)
>>>> - Finally move vc-search-log to 'C-x v s' (Emacs 30)
>>> We could do the first two steps in Emacs 28, perhaps -- if anybody's
>>> actually using `C-x v b', they'll then get
>>> C-x v b-
>>> in the echo area, which should tell them that something's different is
>>> happening now...
>>
>> Works for me.
>>
>> Juri, what do you say?
>
> I think in the long-term it would be nice to have these keybindings:
>
> C-x v B   - vc-switch-backend
> C-x v b c - vc-create-tag (maybe it should have an alias 'vc-create-branch'?)
> C-x v b l - vc-print-branch-log
> C-x v b s - vc-retrieve-tag (maybe it should have an alias 'vc-switch-branch'?)
> C-x v s   - vc-log-search
> C-x v r   - free, any ideas what to bind to it?
>
> Since `C-x v b' will show "C-x v b-" in the echo area,
> and `C-x v s' will show "Search log with pattern: " in the minibuffer.
> and `C-x v r' will show "C-x v r is undefined",
> I see no problem in adding all keybindings before the next release.

Maybe I should express this wish in a separate bug, but:

It would be nice if vc-create-tag allowed to specify start-point
conveniently:

git checkout -b new-branch-name START-POINT

Currently I do this in shell.

Filipp.

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

[Dmitry Gutov]

On 16.09.2021 14:46, Filipp Gunbin wrote:
> Maybe I should express this wish in a separate bug, but:
> 
> It would be nice if vc-create-tag allowed to specify start-point
> conveniently:
> 
> git checkout -b new-branch-name START-POINT
> 
> Currently I do this in shell.

Perhaps we could do that with 'C-u C-u'.

Yes, a separate feature request is preferable.

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

[Filipp Gunbin]

On 16/09/2021 14:54 +0300, Dmitry Gutov wrote:

> On 16.09.2021 14:46, Filipp Gunbin wrote:
>> Maybe I should express this wish in a separate bug, but:
>>
>> It would be nice if vc-create-tag allowed to specify start-point
>> conveniently:
>>
>> git checkout -b new-branch-name START-POINT
>>
>> Currently I do this in shell.
>
> Perhaps we could do that with 'C-u C-u'.
>
> Yes, a separate feature request is preferable.

I'm also thinking of a separate command for branch creation, wrote all
that in bug#50643.  Thanks.

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

[Dmitry Gutov]

On 17.09.2021 18:15, Filipp Gunbin wrote:
> On 16/09/2021 14:54 +0300, Dmitry Gutov wrote:
> 
>> On 16.09.2021 14:46, Filipp Gunbin wrote:
>>> Maybe I should express this wish in a separate bug, but:
>>>
>>> It would be nice if vc-create-tag allowed to specify start-point
>>> conveniently:
>>>
>>> git checkout -b new-branch-name START-POINT
>>>
>>> Currently I do this in shell.
>> Perhaps we could do that with 'C-u C-u'.
>>
>> Yes, a separate feature request is preferable.
> I'm also thinking of a separate command for branch creation, wrote all
> that in bug#50643.  Thanks.

This part might actually fit better in this one: if we add a new command 
which will create a branch by default, then it will fit the new 'b' 
keymap best.

We could actually do the migration this way: create a new command which 
"flips" the branch-tag relationship and put it on 'C-v b c'. Then, if 
we're not removing the 'C-x s' binding in this release, we could 
obsolete the command in favor of the new one because people create 
branches more often tags tags these days (right?).

What do people think?

The command could also prompt for START-POINT by default: it shouldn't 
really hurt to press RET once more at the end. It can also be useful to 
double-check the branch you are currently branching from.

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

[Juri Linkov]

>>>> It would be nice if vc-create-tag allowed to specify start-point
>>>> conveniently:
>>>>
>>>> git checkout -b new-branch-name START-POINT
>>>>
>>>> Currently I do this in shell.
>>> Perhaps we could do that with 'C-u C-u'.
>>>
>>> Yes, a separate feature request is preferable.
>> I'm also thinking of a separate command for branch creation, wrote all
>> that in bug#50643.  Thanks.
>
> This part might actually fit better in this one: if we add a new command
> which will create a branch by default, then it will fit the new 'b'
> keymap best.

👍 for the new branch command.  Until now, I avoided ‘vc-create-tag’
to not make a mistake that will create a tag instead of the branch.

> We could actually do the migration this way: create a new command which
> "flips" the branch-tag relationship and put it on 'C-v b c'. Then, if we're
> not removing the 'C-x s' binding in this release, we could obsolete the
> command in favor of the new one because people create branches more often
> tags tags these days (right?).

Shouldn't tag commands be moved to another prefix key ‘C-x v t’?
But I don't know how often tag commands are used.

> The command could also prompt for START-POINT by default: it shouldn't
> really hurt to press RET once more at the end. It can also be useful to
> double-check the branch you are currently branching from.

A prompt for START-POINT would be fine with completion on branch names,
and saying what the default value will be used when exiting with RET.

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

[Dmitry Gutov]

On 18.09.2021 22:03, Juri Linkov wrote:

>>>> Yes, a separate feature request is preferable.
>>> I'm also thinking of a separate command for branch creation, wrote all
>>> that in bug#50643.  Thanks.
>>
>> This part might actually fit better in this one: if we add a new command
>> which will create a branch by default, then it will fit the new 'b'
>> keymap best.
> 
> 👍 for the new branch command.  Until now, I avoided ‘vc-create-tag’
> to not make a mistake that will create a tag instead of the branch.
> 
>> We could actually do the migration this way: create a new command which
>> "flips" the branch-tag relationship and put it on 'C-v b c'. Then, if we're
>> not removing the 'C-x s' binding in this release, we could obsolete the
>> command in favor of the new one because people create branches more often
>> tags tags these days (right?).
> 
> Shouldn't tag commands be moved to another prefix key ‘C-x v t’?
> But I don't know how often tag commands are used.

So far we only have one tag command, and it doubles for branches with 
'C-u'. The other tag-related command doesn't differentiate between 
branches and tags.

Would having essentially two copies of these, but with different names, 
be a good idea?

Are there some VCS which would benefit from a more stricter 
differentiation between the two? Hg, perhaps? I don't know how branches 
work there.

Either way, we could put the same command in both keymaps, but I also 
don't know how often the tag commands are used for working with _tags_ 
these days.

>> The command could also prompt for START-POINT by default: it shouldn't
>> really hurt to press RET once more at the end. It can also be useful to
>> double-check the branch you are currently branching from.
> 
> A prompt for START-POINT would be fine with completion on branch names,
> and saying what the default value will be used when exiting with RET.

Yup!

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

[Juri Linkov]

> So far we only have one tag command, and it doubles for branches with
> 'C-u'. The other tag-related command doesn't differentiate between branches
> and tags.
>
> Would having essentially two copies of these, but with different names, be
> a good idea?

It makes sense to create a copy where the meaning of its arg
is reversed, so by default it will operate on branches,
and only with C-u on tags.

> Are there some VCS which would benefit from a more stricter differentiation
> between the two? Hg, perhaps? I don't know how branches work there.

So the question is what backends already use the arg 'branchp'?
The search shows that vc-cvs-create-tag, vc-git-create-tag,
vc-hg-create-tag all use this arg.

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

[Dmitry Gutov]

On 19.09.2021 20:04, Juri Linkov wrote:
>> So far we only have one tag command, and it doubles for branches with
>> 'C-u'. The other tag-related command doesn't differentiate between branches
>> and tags.
>>
>> Would having essentially two copies of these, but with different names, be
>> a good idea?
> 
> It makes sense to create a copy where the meaning of its arg
> is reversed, so by default it will operate on branches,
> and only with C-u on tags.

Yup.

But I also wonder if reading START-POINT with completion (with current 
branch name as default) will make sense for creating tags in all 
backends too.

>> Are there some VCS which would benefit from a more stricter differentiation
>> between the two? Hg, perhaps? I don't know how branches work there.
> 
> So the question is what backends already use the arg 'branchp'?
> The search shows that vc-cvs-create-tag, vc-git-create-tag,
> vc-hg-create-tag all use this arg.

I thought of Hg in particular because there was a report or two citing 
some problems with how we handle them.

And: "Mercurial offers a variety of approaches to branching, including 
“named branches”, “bookmarks” (most similar to git), “anonymous 
branches” and using clones." 
(https://markheath.net/post/using-named-branches-in-mercurial)

That's basically all I know about it.

The introduction in 
https://www.draketo.de/software/mercurial-branching-strategy, however, 
sounds very similar to Git's approach.

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

[Juri Linkov]

>> It makes sense to create a copy where the meaning of its arg
>> is reversed, so by default it will operate on branches,
>> and only with C-u on tags.
>
> Yup.
>
> But I also wonder if reading START-POINT with completion (with current
> branch name as default) will make sense for creating tags in all backends
> too.

You mean tag completion for creating tags?  Maybe.

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

[Dmitry Gutov]

On 20.09.2021 09:49, Juri Linkov wrote:
>>> It makes sense to create a copy where the meaning of its arg
>>> is reversed, so by default it will operate on branches,
>>> and only with C-u on tags.
>> Yup.
>>
>> But I also wonder if reading START-POINT with completion (with current
>> branch name as default) will make sense for creating tags in all backends
>> too.
> You mean tag completion for creating tags?  Maybe.

Branch completion. To specify which branch tip to tag.

This seems like an unusual thing to need to do, but if we keep branch 
and tag creation on the same command, and add START-POINT completion by 
default, it might become the expected behavior in both scenarios, no?

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

[Filipp Gunbin]

On 20/09/2021 19:53 +0300, Dmitry Gutov wrote:

> On 20.09.2021 09:49, Juri Linkov wrote:
>>>> It makes sense to create a copy where the meaning of its arg
>>>> is reversed, so by default it will operate on branches,
>>>> and only with C-u on tags.
>>> Yup.
>>>
>>> But I also wonder if reading START-POINT with completion (with current
>>> branch name as default) will make sense for creating tags in all backends
>>> too.
>> You mean tag completion for creating tags?  Maybe.
>
> Branch completion. To specify which branch tip to tag.
>
> This seems like an unusual thing to need to do, but if we keep branch
> and tag creation on the same command, and add START-POINT completion by
> default, it might become the expected behavior in both scenarios, no?

I think also (maybe that's obvious, but still) that START-POINT
auto-completion should include both branches and tags (because it's
common to create a branch off some tag).  Of course, it should allow
specifying arbitrary commit hash.

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

[Filipp Gunbin]

On 18/09/2021 22:03 +0300, Juri Linkov wrote:

> Shouldn't tag commands be moved to another prefix key ‘C-x v t’?
> But I don't know how often tag commands are used.

Sounds good, C-x v t is where I'd look for tag-related commands first.
However, I don't use tags much (besides creation - only "git fetch
--tags"), so I cannot add anything meaningful here.

Otherwise, the plan for C-x v b prefix looks great.

Other commands, like maybe "C-x v b r" - rename, could be added then.

Filipp

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

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 1303 bytes --]

>>> Maybe I should express this wish in a separate bug, but:
>>>
>>> It would be nice if vc-create-tag allowed to specify start-point
>>> conveniently:
>>>
>>> git checkout -b new-branch-name START-POINT
>>>
>>> Currently I do this in shell.
>>
>> Perhaps we could do that with 'C-u C-u'.
>>
>> Yes, a separate feature request is preferable.
>
> I'm also thinking of a separate command for branch creation, wrote all
> that in bug#50643.  Thanks.

The following patch adds two new branch commands.

> However, I don't use tags much (besides creation - only "git fetch
> --tags"), so I cannot add anything meaningful here.
> Otherwise, the plan for C-x v b prefix looks great.
> Other commands, like maybe "C-x v b r" - rename, could be added then.

I can't find the existing vc API method for renaming tags/branches.

> 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: ") ...


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: vc-switch-branch.patch --]
[-- Type: text/x-diff, Size: 3911 bytes --]

diff --git a/lisp/vc/vc-hooks.el b/lisp/vc/vc-hooks.el
index b7760e3bba..2b6ebdfb74 100644
--- a/lisp/vc/vc-hooks.el
+++ b/lisp/vc/vc-hooks.el
@@ -865,6 +865,9 @@ vc-prefix-map
   (let ((map (make-sparse-keymap)))
     (define-key map "a" #'vc-update-change-log)
     (define-key map "b" #'vc-switch-backend)
+    (define-key map "Bc" #'vc-create-branch)
+    (define-key map "Bl" #'vc-print-branch-log)
+    (define-key map "Bs" #'vc-switch-branch)
     (define-key map "d" #'vc-dir)
     (define-key map "g" #'vc-annotate)
     (define-key map "G" #'vc-ignore)
diff --git a/lisp/vc/vc.el b/lisp/vc/vc.el
index edc4169465..cdebf4a3d3 100644
--- a/lisp/vc/vc.el
+++ b/lisp/vc/vc.el
@@ -2350,7 +2372,23 @@ vc-create-tag
   (message "Making %s... done" (if branchp "branch" "tag")))
 
 ;;;###autoload
-(defun vc-retrieve-tag (dir name)
+(defun vc-create-branch (dir name)
+  "Descending recursively from DIR, make a branch called NAME.
+After a new branch is made, the files are checked out in that new branch.
+Uses `vc-create-tag' with the non-nil arg `branchp'."
+  (interactive
+   (let ((granularity
+	  (vc-call-backend (vc-responsible-backend default-directory)
+			   'revision-granularity)))
+     (list
+      (if (eq granularity 'repository)
+	  default-directory
+	(read-directory-name "Directory: " default-directory default-directory t))
+      (read-string "New branch name: " nil 'vc-revision-history))))
+  (vc-create-tag dir name t))
+
+;;;###autoload
+(defun vc-retrieve-tag (dir name &optional branchp)
   "For each file in or below DIR, retrieve their tagged version NAME.
 NAME can name a branch, in which case this command will switch to the
 named branch in the directory DIR.
@@ -2375,15 +2413,21 @@ vc-retrieve-tag
              (read-directory-name "Directory: " default-directory nil t))))
      (list
       dir
-      (vc-read-revision (format-prompt "Tag name to retrieve" "latest revisions")
+      (vc-read-revision (format-prompt
+                         (if current-prefix-arg
+                             "Branch name to retrieve"
+                           "Tag name to retrieve")
+                         "latest revisions")
                         (list dir)
-                        (vc-responsible-backend dir)))))
+                        (vc-responsible-backend dir))
+      current-prefix-arg)))
   (let* ((backend (vc-responsible-backend dir))
          (update (when (vc-call-backend backend 'update-on-retrieve-tag)
                    (yes-or-no-p "Update any affected buffers? ")))
 	 (msg (if (or (not name) (string= name ""))
 		  (format "Updating %s... " (abbreviate-file-name dir))
-	        (format "Retrieving tag %s into %s... "
+	        (format "Retrieving %s %s into %s... "
+                        (if branchp "branch" "tag")
 		        name (abbreviate-file-name dir)))))
     (message "%s" msg)
     (vc-call-backend backend 'retrieve-tag dir name update)
@@ -2391,6 +2435,25 @@ vc-retrieve-tag
     (run-hooks 'vc-retrieve-tag-hook)
     (message "%s" (concat msg "done"))))
 
+;;;###autoload
+(defun vc-switch-branch (dir name)
+  "Switch to the branch NAME in the directory DIR.
+If NAME is empty, it refers to the latest revisions of the current branch.
+Uses `vc-retrieve-tag' with the non-nil arg `branchp'."
+  (interactive
+   (let* ((granularity
+           (vc-call-backend (vc-responsible-backend default-directory)
+                            'revision-granularity))
+          (dir
+           (if (eq granularity 'repository)
+               (expand-file-name (vc-root-dir))
+             (read-directory-name "Directory: " default-directory nil t))))
+     (list
+      dir
+      (vc-read-revision (format-prompt "Branch name to retrieve" "latest revisions")
+                        (list dir)
+                        (vc-responsible-backend dir)))))
+  (vc-retrieve-tag dir name t))
 
 ;; Miscellaneous other entry points
 

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

[Dmitry Gutov]

On 05.10.2021 20:43, Juri Linkov wrote:

>> I'm also thinking of a separate command for branch creation, wrote all
>> that in bug#50643.  Thanks.
> 
> The following patch adds two new branch commands.
> 
>> However, I don't use tags much (besides creation - only "git fetch
>> --tags"), so I cannot add anything meaningful here.
>> Otherwise, the plan for C-x v b prefix looks great.
>> Other commands, like maybe "C-x v b r" - rename, could be added then.
> 
> I can't find the existing vc API method for renaming tags/branches.

I think that's OK.

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

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.

As long as the ability to read and show the current ref/branch is there 
for most backends (to show it as the default input in the prompt).

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?

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

[Dmitry Gutov]

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.

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

[Juri Linkov]

>>> Other commands, like maybe "C-x v b r" - rename, could be added then.
>> I can't find the existing vc API method for renaming tags/branches.
>
> I think that's OK.

But even the current branch creating command fails for git.
For example, 'C-u C-x v s new_branch RET' fails with the error:

  (error "Failed (status 1): git --no-pager update-index --refresh .")

and shows the *vc* buffer saying that modified files need update.

Whereas `M-& git checkout -b new_branch` works fine with modified files.

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

[Dmitry Gutov]

On 06.10.2021 19:28, Juri Linkov wrote:
>>>> Other commands, like maybe "C-x v b r" - rename, could be added then.
>>> I can't find the existing vc API method for renaming tags/branches.
>> I think that's OK.
> But even the current branch creating command fails for git.
> For example, 'C-u C-x v s new_branch RET' fails with the error:
> 
>    (error "Failed (status 1): git --no-pager update-index --refresh .")
> 
> and shows the*vc*  buffer saying that modified files need update.
> 
> Whereas `M-& git checkout -b new_branch` works fine with modified files.

All right, yes, the current behavior is weird. It's actually documented 
in the description of the 'create-tag' action:

;;   Attach the tag NAME to the state of the working copy.  This
;;   should make sure that files are up-to-date before proceeding with
;;   the action.

Perhaps ESR or Dan N. have a good justification for this, but it seems 
to me the contemporary expectation is that tags and branches are created 
from the committed revision history, and not from the "working copy".

Some backends may choose to enforce this kind of limitation, but the 
more modern ones like Git or Hg should skip the check IMHO.

And it seems, from looking at vc-hg-create-tag, Hg already skips it.

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

[Filipp Gunbin]

Thanks, two very minor doc comments:

> +;;;###autoload
> +(defun vc-retrieve-tag (dir name &optional branchp)
>    "For each file in or below DIR, retrieve their tagged version NAME.
>  NAME can name a branch, in which case this command will switch to the
>  named branch in the directory DIR.
> @@ -2375,15 +2413,21 @@ vc-retrieve-tag
>               (read-directory-name "Directory: " default-directory nil t))))
>       (list
>        dir
> -      (vc-read-revision (format-prompt "Tag name to retrieve" "latest revisions")
> +      (vc-read-revision (format-prompt
> +                         (if current-prefix-arg
> +                             "Branch name to retrieve"
> +                           "Tag name to retrieve")
> +                         "latest revisions")

Mention prefix arg in the docstring?

> +(defun vc-switch-branch (dir name)
> +  "Switch to the branch NAME in the directory DIR.
> +If NAME is empty, it refers to the latest revisions of the current branch.
> +Uses `vc-retrieve-tag' with the non-nil arg `branchp'."

"latest revision" instead of plural?

Filipp.

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

[Robert Pluim]

>>>>> On Thu, 07 Oct 2021 15:46:47 +0300, Filipp Gunbin <fgunbin@fastmail.fm> said:

    >> +(defun vc-switch-branch (dir name)
    >> +  "Switch to the branch NAME in the directory DIR.
    >> +If NAME is empty, it refers to the latest revisions of the current branch.
    >> +Uses `vc-retrieve-tag' with the non-nil arg `branchp'."

    Filipp> "latest revision" instead of plural?

Some version control systems have branches, but also have per-file
revisions.

Robert
-- 

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

[Juri Linkov]

> Thanks, two very minor doc comments:
>
>> +;;;###autoload
>> +(defun vc-retrieve-tag (dir name &optional branchp)
>>    "For each file in or below DIR, retrieve their tagged version NAME.
>>  NAME can name a branch, in which case this command will switch to the
>>  named branch in the directory DIR.
>> @@ -2375,15 +2413,21 @@ vc-retrieve-tag
>>               (read-directory-name "Directory: " default-directory nil t))))
>>       (list
>>        dir
>> -      (vc-read-revision (format-prompt "Tag name to retrieve" "latest revisions")
>> +      (vc-read-revision (format-prompt
>> +                         (if current-prefix-arg
>> +                             "Branch name to retrieve"
>> +                           "Tag name to retrieve")
>> +                         "latest revisions")
>
> Mention prefix arg in the docstring?

Thanks for noticing, will be added in the next version of the patch.

>> +(defun vc-switch-branch (dir name)
>> +  "Switch to the branch NAME in the directory DIR.
>> +If NAME is empty, it refers to the latest revisions of the current branch.
>> +Uses `vc-retrieve-tag' with the non-nil arg `branchp'."
>
> "latest revision" instead of plural?

This text was copied from vc-retrieve-tag, and Robert explained why
it's plural.  But since this phrase is too confusing, maybe it would be
possible to rephrase it with a better text?

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

[Dmitry Gutov]

On 04.09.2021 09:33, Lars Ingebrigtsen wrote:

>> On 03.09.2021 19:18, Juri Linkov wrote:
>>> I think we want more to remove another duplicate key 'C-x v s'
>>> because then we could bind it to 'vc-log-search'.
>>
>> That works for me. And indeed vc-log-search seems more important.
>>
>> What do others think?
> 
> Then it would be only on `B c' in vc-dir-mode?

Yup.

> `C-x v s' isn't very
> mnemonic,

Apparently the original name was "snapshot". Like, when you create a 
tag, you snapshot the whole current state of the repo.

See commit 370fded4f6c where the mass renaming was made.

> but would removing it from global map inconvenience people?
> (I've never used it myself.)

I don't use a whole bunch of commands that are easy to type in the 
console (and fish completion helps a lot), so maybe others will chime in.

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

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

>> `C-x v s' isn't very
>> mnemonic,
>
> Apparently the original name was "snapshot". Like, when you create a
> tag, you snapshot the whole current state of the repo.

Ah, I see -- that makes sense.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no