* bug#50344: C-x v keybinding for vc-print-branch-log @ 2021-09-02 18:43 Juri Linkov 2021-09-02 23:24 ` Dmitry Gutov 0 siblings, 1 reply; 91+ messages in thread From: Juri Linkov @ 2021-09-02 18:43 UTC (permalink / raw) To: 50344 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) ^ permalink raw reply related [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-09-02 18:43 bug#50344: C-x v keybinding for vc-print-branch-log Juri Linkov @ 2021-09-02 23:24 ` Dmitry Gutov 2021-09-03 8:15 ` Juri Linkov 2021-09-03 16:18 ` Juri Linkov 0 siblings, 2 replies; 91+ messages in thread From: Dmitry Gutov @ 2021-09-02 23:24 UTC (permalink / raw) To: Juri Linkov, 50344 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. ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-09-02 23:24 ` Dmitry Gutov @ 2021-09-03 8:15 ` Juri Linkov 2021-09-03 12:26 ` Dmitry Gutov 2021-09-03 16:18 ` Juri Linkov 1 sibling, 1 reply; 91+ messages in thread From: Juri Linkov @ 2021-09-03 8:15 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 50344 >> + (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? ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-09-03 8:15 ` Juri Linkov @ 2021-09-03 12:26 ` Dmitry Gutov 0 siblings, 0 replies; 91+ messages in thread From: Dmitry Gutov @ 2021-09-03 12:26 UTC (permalink / raw) To: Juri Linkov; +Cc: 50344 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. ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-09-02 23:24 ` Dmitry Gutov 2021-09-03 8:15 ` Juri Linkov @ 2021-09-03 16:18 ` Juri Linkov 2021-09-03 16:41 ` Dmitry Gutov 1 sibling, 1 reply; 91+ messages in thread From: Juri Linkov @ 2021-09-03 16:18 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 50344 >> + (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'. ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-09-03 16:18 ` Juri Linkov @ 2021-09-03 16:41 ` Dmitry Gutov 2021-09-04 6:33 ` Lars Ingebrigtsen 0 siblings, 1 reply; 91+ messages in thread From: Dmitry Gutov @ 2021-09-03 16:41 UTC (permalink / raw) To: Juri Linkov; +Cc: 50344 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? ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-09-03 16:41 ` Dmitry Gutov @ 2021-09-04 6:33 ` Lars Ingebrigtsen 2021-09-05 16:28 ` Juri Linkov 2021-09-08 2:50 ` Dmitry Gutov 0 siblings, 2 replies; 91+ messages in thread From: Lars Ingebrigtsen @ 2021-09-04 6:33 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 50344, Juri Linkov 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-09-04 6:33 ` Lars Ingebrigtsen @ 2021-09-05 16:28 ` Juri Linkov 2021-09-06 8:25 ` Lars Ingebrigtsen 2021-09-08 2:50 ` Dmitry Gutov 1 sibling, 1 reply; 91+ messages in thread From: Juri Linkov @ 2021-09-05 16:28 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 50344, Dmitry Gutov >>> 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) ^ permalink raw reply related [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-09-05 16:28 ` Juri Linkov @ 2021-09-06 8:25 ` Lars Ingebrigtsen 2021-09-06 15:19 ` Juri Linkov 0 siblings, 1 reply; 91+ messages in thread From: Lars Ingebrigtsen @ 2021-09-06 8:25 UTC (permalink / raw) To: Juri Linkov; +Cc: 50344, Dmitry Gutov 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-09-06 8:25 ` Lars Ingebrigtsen @ 2021-09-06 15:19 ` Juri Linkov 2021-09-07 15:05 ` Lars Ingebrigtsen 0 siblings, 1 reply; 91+ messages in thread From: Juri Linkov @ 2021-09-06 15:19 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 50344, Dmitry Gutov >>> 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... ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-09-06 15:19 ` Juri Linkov @ 2021-09-07 15:05 ` Lars Ingebrigtsen 2021-09-08 2:58 ` Dmitry Gutov 0 siblings, 1 reply; 91+ messages in thread From: Lars Ingebrigtsen @ 2021-09-07 15:05 UTC (permalink / raw) To: Juri Linkov; +Cc: 50344, Dmitry Gutov 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-09-07 15:05 ` Lars Ingebrigtsen @ 2021-09-08 2:58 ` Dmitry Gutov 2021-09-08 8:00 ` Lars Ingebrigtsen 0 siblings, 1 reply; 91+ messages in thread From: Dmitry Gutov @ 2021-09-08 2:58 UTC (permalink / raw) To: Lars Ingebrigtsen, Juri Linkov; +Cc: 50344 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) ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-09-08 2:58 ` Dmitry Gutov @ 2021-09-08 8:00 ` Lars Ingebrigtsen 2021-09-08 11:59 ` Dmitry Gutov 0 siblings, 1 reply; 91+ messages in thread From: Lars Ingebrigtsen @ 2021-09-08 8:00 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 50344, Juri Linkov 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-09-08 8:00 ` Lars Ingebrigtsen @ 2021-09-08 11:59 ` Dmitry Gutov 2021-09-09 17:39 ` Juri Linkov 0 siblings, 1 reply; 91+ messages in thread From: Dmitry Gutov @ 2021-09-08 11:59 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 50344, Juri Linkov 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? ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-09-08 11:59 ` Dmitry Gutov @ 2021-09-09 17:39 ` Juri Linkov 2021-09-09 23:18 ` Dmitry Gutov ` (2 more replies) 0 siblings, 3 replies; 91+ messages in thread From: Juri Linkov @ 2021-09-09 17:39 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 50344, Lars Ingebrigtsen >>> 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. ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-09-09 17:39 ` Juri Linkov @ 2021-09-09 23:18 ` Dmitry Gutov 2021-09-10 6:46 ` Juri Linkov 2021-09-10 10:32 ` Lars Ingebrigtsen 2021-09-16 11:46 ` Filipp Gunbin 2 siblings, 1 reply; 91+ messages in thread From: Dmitry Gutov @ 2021-09-09 23:18 UTC (permalink / raw) To: Juri Linkov; +Cc: 50344, Lars Ingebrigtsen 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. ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-09-09 23:18 ` Dmitry Gutov @ 2021-09-10 6:46 ` Juri Linkov 2021-09-10 11:27 ` Dmitry Gutov 0 siblings, 1 reply; 91+ messages in thread From: Juri Linkov @ 2021-09-10 6:46 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 50344, Lars Ingebrigtsen >> 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), ... ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-09-10 6:46 ` Juri Linkov @ 2021-09-10 11:27 ` Dmitry Gutov 0 siblings, 0 replies; 91+ messages in thread From: Dmitry Gutov @ 2021-09-10 11:27 UTC (permalink / raw) To: Juri Linkov; +Cc: 50344, Lars Ingebrigtsen 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. ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-09-09 17:39 ` Juri Linkov 2021-09-09 23:18 ` Dmitry Gutov @ 2021-09-10 10:32 ` Lars Ingebrigtsen 2021-09-10 11:26 ` Dmitry Gutov 2021-09-16 11:46 ` Filipp Gunbin 2 siblings, 1 reply; 91+ messages in thread From: Lars Ingebrigtsen @ 2021-09-10 10:32 UTC (permalink / raw) To: Juri Linkov; +Cc: 50344, Dmitry Gutov 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-09-10 10:32 ` Lars Ingebrigtsen @ 2021-09-10 11:26 ` Dmitry Gutov 2021-09-13 7:47 ` Juri Linkov 0 siblings, 1 reply; 91+ messages in thread From: Dmitry Gutov @ 2021-09-10 11:26 UTC (permalink / raw) To: Lars Ingebrigtsen, Juri Linkov; +Cc: 50344 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. ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-09-10 11:26 ` Dmitry Gutov @ 2021-09-13 7:47 ` Juri Linkov 2021-10-07 7:21 ` Juri Linkov 0 siblings, 1 reply; 91+ messages in thread From: Juri Linkov @ 2021-09-13 7:47 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 50344, Lars Ingebrigtsen >> 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'. ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-09-13 7:47 ` Juri Linkov @ 2021-10-07 7:21 ` Juri Linkov 2021-10-07 7:47 ` Eli Zaretskii 0 siblings, 1 reply; 91+ messages in thread From: Juri Linkov @ 2021-10-07 7:21 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 50344, Lars Ingebrigtsen [-- 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) ^ permalink raw reply related [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-10-07 7:21 ` Juri Linkov @ 2021-10-07 7:47 ` Eli Zaretskii 2021-10-07 7:58 ` Juri Linkov 0 siblings, 1 reply; 91+ messages in thread From: Eli Zaretskii @ 2021-10-07 7:47 UTC (permalink / raw) To: Juri Linkov; +Cc: 50344, larsi, dgutov > 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.) ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-10-07 7:47 ` Eli Zaretskii @ 2021-10-07 7:58 ` Juri Linkov 2021-10-07 8:28 ` Eli Zaretskii 2021-10-07 9:57 ` Gregory Heytings 0 siblings, 2 replies; 91+ messages in thread From: Juri Linkov @ 2021-10-07 7:58 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 50344, larsi, dgutov >> 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. ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-10-07 7:58 ` Juri Linkov @ 2021-10-07 8:28 ` Eli Zaretskii 2021-10-07 11:12 ` Dmitry Gutov 2021-10-07 9:57 ` Gregory Heytings 1 sibling, 1 reply; 91+ messages in thread From: Eli Zaretskii @ 2021-10-07 8:28 UTC (permalink / raw) To: Juri Linkov; +Cc: 50344, larsi, dgutov > 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. ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-10-07 8:28 ` Eli Zaretskii @ 2021-10-07 11:12 ` Dmitry Gutov 2021-10-07 12:56 ` Eli Zaretskii 0 siblings, 1 reply; 91+ messages in thread From: Dmitry Gutov @ 2021-10-07 11:12 UTC (permalink / raw) To: Eli Zaretskii, Juri Linkov; +Cc: 50344, larsi 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? ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-10-07 11:12 ` Dmitry Gutov @ 2021-10-07 12:56 ` Eli Zaretskii 2021-10-07 13:06 ` Dmitry Gutov 2021-10-07 13:11 ` Robert Pluim 0 siblings, 2 replies; 91+ messages in thread From: Eli Zaretskii @ 2021-10-07 12:56 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 50344, larsi, juri > 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. ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-10-07 12:56 ` Eli Zaretskii @ 2021-10-07 13:06 ` Dmitry Gutov 2021-10-07 13:21 ` Eli Zaretskii 2021-10-07 13:11 ` Robert Pluim 1 sibling, 1 reply; 91+ messages in thread From: Dmitry Gutov @ 2021-10-07 13:06 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 50344, larsi, juri 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. ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-10-07 13:06 ` Dmitry Gutov @ 2021-10-07 13:21 ` Eli Zaretskii 2021-10-07 13:26 ` Dmitry Gutov ` (2 more replies) 0 siblings, 3 replies; 91+ messages in thread From: Eli Zaretskii @ 2021-10-07 13:21 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 50344, larsi, juri > 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. ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-10-07 13:21 ` Eli Zaretskii @ 2021-10-07 13:26 ` Dmitry Gutov 2021-10-07 13:50 ` Eli Zaretskii 2021-10-07 17:36 ` Juri Linkov 2021-10-07 21:49 ` Dmitry Gutov 2 siblings, 1 reply; 91+ messages in thread From: Dmitry Gutov @ 2021-10-07 13:26 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 50344, larsi, juri 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. ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-10-07 13:26 ` Dmitry Gutov @ 2021-10-07 13:50 ` Eli Zaretskii 0 siblings, 0 replies; 91+ messages in thread From: Eli Zaretskii @ 2021-10-07 13:50 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 50344, larsi, juri > 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. ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-10-07 13:21 ` Eli Zaretskii 2021-10-07 13:26 ` Dmitry Gutov @ 2021-10-07 17:36 ` Juri Linkov 2021-10-07 18:22 ` Eli Zaretskii 2021-10-07 21:49 ` Dmitry Gutov 2 siblings, 1 reply; 91+ messages in thread From: Juri Linkov @ 2021-10-07 17:36 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 50344, larsi, Dmitry Gutov >> 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. ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-10-07 17:36 ` Juri Linkov @ 2021-10-07 18:22 ` Eli Zaretskii 0 siblings, 0 replies; 91+ messages in thread From: Eli Zaretskii @ 2021-10-07 18:22 UTC (permalink / raw) To: Juri Linkov; +Cc: 50344, larsi, dgutov > 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. ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-10-07 13:21 ` Eli Zaretskii 2021-10-07 13:26 ` Dmitry Gutov 2021-10-07 17:36 ` Juri Linkov @ 2021-10-07 21:49 ` Dmitry Gutov 2021-10-12 12:48 ` Filipp Gunbin 2 siblings, 1 reply; 91+ messages in thread From: Dmitry Gutov @ 2021-10-07 21:49 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 50344, larsi, juri 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. ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-10-07 21:49 ` Dmitry Gutov @ 2021-10-12 12:48 ` Filipp Gunbin 2021-10-13 1:45 ` Dmitry Gutov 0 siblings, 1 reply; 91+ messages in thread From: Filipp Gunbin @ 2021-10-12 12:48 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 50344, larsi, juri 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-10-12 12:48 ` Filipp Gunbin @ 2021-10-13 1:45 ` Dmitry Gutov 2021-10-13 10:12 ` Filipp Gunbin 0 siblings, 1 reply; 91+ messages in thread From: Dmitry Gutov @ 2021-10-13 1:45 UTC (permalink / raw) To: Filipp Gunbin; +Cc: 50344, larsi, juri 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. ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-10-13 1:45 ` Dmitry Gutov @ 2021-10-13 10:12 ` Filipp Gunbin 2021-10-13 23:37 ` Dmitry Gutov 0 siblings, 1 reply; 91+ messages in thread From: Filipp Gunbin @ 2021-10-13 10:12 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 50344, larsi, juri 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.. ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-10-13 10:12 ` Filipp Gunbin @ 2021-10-13 23:37 ` Dmitry Gutov 2021-12-24 11:56 ` Philip Kaludercic 2022-09-09 5:46 ` Sean Whitton 0 siblings, 2 replies; 91+ messages in thread From: Dmitry Gutov @ 2021-10-13 23:37 UTC (permalink / raw) To: Filipp Gunbin; +Cc: 50344, larsi, juri 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. ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-10-13 23:37 ` Dmitry Gutov @ 2021-12-24 11:56 ` Philip Kaludercic 2021-12-24 12:03 ` Dmitry Gutov 2022-09-09 5:46 ` Sean Whitton 1 sibling, 1 reply; 91+ messages in thread From: Philip Kaludercic @ 2021-12-24 11:56 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 50344, larsi, Filipp Gunbin, juri 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-12-24 11:56 ` Philip Kaludercic @ 2021-12-24 12:03 ` Dmitry Gutov 2021-12-24 13:57 ` Philip Kaludercic 0 siblings, 1 reply; 91+ messages in thread From: Dmitry Gutov @ 2021-12-24 12:03 UTC (permalink / raw) To: Philip Kaludercic; +Cc: 50344, larsi, Filipp Gunbin, juri 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? ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-12-24 12:03 ` Dmitry Gutov @ 2021-12-24 13:57 ` Philip Kaludercic 2021-12-24 23:45 ` Dmitry Gutov 0 siblings, 1 reply; 91+ messages in thread From: Philip Kaludercic @ 2021-12-24 13:57 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 50344 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-12-24 13:57 ` Philip Kaludercic @ 2021-12-24 23:45 ` Dmitry Gutov 2021-12-25 11:37 ` Philip Kaludercic 0 siblings, 1 reply; 91+ messages in thread From: Dmitry Gutov @ 2021-12-24 23:45 UTC (permalink / raw) To: Philip Kaludercic; +Cc: 50344 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. ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-12-24 23:45 ` Dmitry Gutov @ 2021-12-25 11:37 ` Philip Kaludercic 2021-12-25 12:08 ` Dmitry Gutov 0 siblings, 1 reply; 91+ messages in thread From: Philip Kaludercic @ 2021-12-25 11:37 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 50344 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-12-25 11:37 ` Philip Kaludercic @ 2021-12-25 12:08 ` Dmitry Gutov 0 siblings, 0 replies; 91+ messages in thread From: Dmitry Gutov @ 2021-12-25 12:08 UTC (permalink / raw) To: Philip Kaludercic; +Cc: 50344 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. ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-10-13 23:37 ` Dmitry Gutov 2021-12-24 11:56 ` Philip Kaludercic @ 2022-09-09 5:46 ` Sean Whitton 2022-09-09 6:29 ` Juri Linkov 2022-09-11 15:10 ` Juri Linkov 1 sibling, 2 replies; 91+ messages in thread From: Sean Whitton @ 2022-09-09 5:46 UTC (permalink / raw) To: Dmitry Gutov, Filipp Gunbin, 50344, larsi, juri 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2022-09-09 5:46 ` Sean Whitton @ 2022-09-09 6:29 ` Juri Linkov 2022-09-09 17:09 ` Lars Ingebrigtsen 2022-09-11 15:10 ` Juri Linkov 1 sibling, 1 reply; 91+ messages in thread From: Juri Linkov @ 2022-09-09 6:29 UTC (permalink / raw) To: Sean Whitton; +Cc: 50344, larsi, Filipp Gunbin, Dmitry Gutov >> 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. ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2022-09-09 6:29 ` Juri Linkov @ 2022-09-09 17:09 ` Lars Ingebrigtsen 0 siblings, 0 replies; 91+ messages in thread From: Lars Ingebrigtsen @ 2022-09-09 17:09 UTC (permalink / raw) To: Juri Linkov; +Cc: 50344, Dmitry Gutov, Filipp Gunbin, Sean Whitton Juri Linkov <juri@linkov.net> writes: > Agreed. I could try to prepare a complete patch tomorrow. Sounds good. ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2022-09-09 5:46 ` Sean Whitton 2022-09-09 6:29 ` Juri Linkov @ 2022-09-11 15:10 ` Juri Linkov 2022-09-11 15:25 ` Lars Ingebrigtsen 1 sibling, 1 reply; 91+ messages in thread From: Juri Linkov @ 2022-09-11 15:10 UTC (permalink / raw) To: Sean Whitton; +Cc: 50344, larsi, Filipp Gunbin, Dmitry Gutov [-- 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)) ^ permalink raw reply related [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2022-09-11 15:10 ` Juri Linkov @ 2022-09-11 15:25 ` Lars Ingebrigtsen 2022-09-12 18:07 ` Juri Linkov 0 siblings, 1 reply; 91+ messages in thread From: Lars Ingebrigtsen @ 2022-09-11 15:25 UTC (permalink / raw) To: Juri Linkov; +Cc: 50344, Dmitry Gutov, Filipp Gunbin, Sean Whitton 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). ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2022-09-11 15:25 ` Lars Ingebrigtsen @ 2022-09-12 18:07 ` Juri Linkov 2022-09-12 18:21 ` Eli Zaretskii 2022-09-12 18:57 ` Sean Whitton 0 siblings, 2 replies; 91+ messages in thread From: Juri Linkov @ 2022-09-12 18:07 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 50344, Dmitry Gutov, Filipp Gunbin, Sean Whitton 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. ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2022-09-12 18:07 ` Juri Linkov @ 2022-09-12 18:21 ` Eli Zaretskii 2022-09-12 19:13 ` Juri Linkov 2022-09-12 18:57 ` Sean Whitton 1 sibling, 1 reply; 91+ messages in thread From: Eli Zaretskii @ 2022-09-12 18:21 UTC (permalink / raw) To: Juri Linkov; +Cc: 50344, larsi, spwhitton, fgunbin, dgutov > 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? ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2022-09-12 18:21 ` Eli Zaretskii @ 2022-09-12 19:13 ` Juri Linkov 2022-09-13 12:24 ` Eli Zaretskii 0 siblings, 1 reply; 91+ messages in thread From: Juri Linkov @ 2022-09-12 19:13 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 50344, larsi, spwhitton, fgunbin, dgutov >> > 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. ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2022-09-12 19:13 ` Juri Linkov @ 2022-09-13 12:24 ` Eli Zaretskii 0 siblings, 0 replies; 91+ messages in thread From: Eli Zaretskii @ 2022-09-13 12:24 UTC (permalink / raw) To: Juri Linkov; +Cc: 50344, larsi, spwhitton, fgunbin, dgutov > 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! ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2022-09-12 18:07 ` Juri Linkov 2022-09-12 18:21 ` Eli Zaretskii @ 2022-09-12 18:57 ` Sean Whitton 1 sibling, 0 replies; 91+ messages in thread From: Sean Whitton @ 2022-09-12 18:57 UTC (permalink / raw) To: Juri Linkov, Lars Ingebrigtsen, Dmitry Gutov, Filipp Gunbin, 50344 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-10-07 12:56 ` Eli Zaretskii 2021-10-07 13:06 ` Dmitry Gutov @ 2021-10-07 13:11 ` Robert Pluim 2021-10-07 13:51 ` Filipp Gunbin 1 sibling, 1 reply; 91+ messages in thread From: Robert Pluim @ 2021-10-07 13:11 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 50344, larsi, Dmitry Gutov, juri >>>>> 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 -- ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-10-07 13:11 ` Robert Pluim @ 2021-10-07 13:51 ` Filipp Gunbin 0 siblings, 0 replies; 91+ messages in thread From: Filipp Gunbin @ 2021-10-07 13:51 UTC (permalink / raw) To: Robert Pluim; +Cc: 50344, Dmitry Gutov, larsi, juri 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-10-07 7:58 ` Juri Linkov 2021-10-07 8:28 ` Eli Zaretskii @ 2021-10-07 9:57 ` Gregory Heytings 2021-10-07 11:14 ` Dmitry Gutov 2021-10-07 12:51 ` Eli Zaretskii 1 sibling, 2 replies; 91+ messages in thread From: Gregory Heytings @ 2021-10-07 9:57 UTC (permalink / raw) To: Juri Linkov; +Cc: 50344, larsi, dgutov > > 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? ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-10-07 9:57 ` Gregory Heytings @ 2021-10-07 11:14 ` Dmitry Gutov 2021-10-07 11:25 ` Gregory Heytings 2021-10-07 12:51 ` Eli Zaretskii 1 sibling, 1 reply; 91+ messages in thread From: Dmitry Gutov @ 2021-10-07 11:14 UTC (permalink / raw) To: Gregory Heytings, Juri Linkov; +Cc: 50344, larsi 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? ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-10-07 11:14 ` Dmitry Gutov @ 2021-10-07 11:25 ` Gregory Heytings 2021-10-07 11:35 ` Dmitry Gutov 0 siblings, 1 reply; 91+ messages in thread From: Gregory Heytings @ 2021-10-07 11:25 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 50344, larsi, Juri Linkov >>> 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. ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-10-07 11:25 ` Gregory Heytings @ 2021-10-07 11:35 ` Dmitry Gutov 2021-10-07 11:42 ` Gregory Heytings ` (2 more replies) 0 siblings, 3 replies; 91+ messages in thread From: Dmitry Gutov @ 2021-10-07 11:35 UTC (permalink / raw) To: Gregory Heytings; +Cc: 50344, larsi, Juri Linkov 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. ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-10-07 11:35 ` Dmitry Gutov @ 2021-10-07 11:42 ` Gregory Heytings 2021-10-07 12:25 ` Kévin Le Gouguec 2021-10-07 12:42 ` Filipp Gunbin 2021-10-07 13:11 ` Eli Zaretskii 2 siblings, 1 reply; 91+ messages in thread From: Gregory Heytings @ 2021-10-07 11:42 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 50344, larsi, Juri Linkov > > 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. ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-10-07 11:42 ` Gregory Heytings @ 2021-10-07 12:25 ` Kévin Le Gouguec 0 siblings, 0 replies; 91+ messages in thread From: Kévin Le Gouguec @ 2021-10-07 12:25 UTC (permalink / raw) To: Gregory Heytings; +Cc: 50344, larsi, Dmitry Gutov, Juri Linkov 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-10-07 11:35 ` Dmitry Gutov 2021-10-07 11:42 ` Gregory Heytings @ 2021-10-07 12:42 ` Filipp Gunbin 2021-10-07 12:53 ` Dmitry Gutov 2021-10-07 13:11 ` Eli Zaretskii 2 siblings, 1 reply; 91+ messages in thread From: Filipp Gunbin @ 2021-10-07 12:42 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 50344, Gregory Heytings, larsi, Juri Linkov 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? ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-10-07 12:42 ` Filipp Gunbin @ 2021-10-07 12:53 ` Dmitry Gutov 0 siblings, 0 replies; 91+ messages in thread From: Dmitry Gutov @ 2021-10-07 12:53 UTC (permalink / raw) To: Filipp Gunbin; +Cc: 50344, Gregory Heytings, larsi, Juri Linkov 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. ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-10-07 11:35 ` Dmitry Gutov 2021-10-07 11:42 ` Gregory Heytings 2021-10-07 12:42 ` Filipp Gunbin @ 2021-10-07 13:11 ` Eli Zaretskii 2 siblings, 0 replies; 91+ messages in thread From: Eli Zaretskii @ 2021-10-07 13:11 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 50344, gregory, larsi, juri > 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? ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-10-07 9:57 ` Gregory Heytings 2021-10-07 11:14 ` Dmitry Gutov @ 2021-10-07 12:51 ` Eli Zaretskii 2021-10-07 17:30 ` Juri Linkov 1 sibling, 1 reply; 91+ messages in thread From: Eli Zaretskii @ 2021-10-07 12:51 UTC (permalink / raw) To: Gregory Heytings; +Cc: 50344, larsi, juri, dgutov > 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). ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-10-07 12:51 ` Eli Zaretskii @ 2021-10-07 17:30 ` Juri Linkov 2021-10-07 18:25 ` Eli Zaretskii 0 siblings, 1 reply; 91+ messages in thread From: Juri Linkov @ 2021-10-07 17:30 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 50344, Gregory Heytings, larsi, dgutov > 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. ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-10-07 17:30 ` Juri Linkov @ 2021-10-07 18:25 ` Eli Zaretskii 0 siblings, 0 replies; 91+ messages in thread From: Eli Zaretskii @ 2021-10-07 18:25 UTC (permalink / raw) To: Juri Linkov; +Cc: 50344, gregory, larsi, dgutov > 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. ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-09-09 17:39 ` Juri Linkov 2021-09-09 23:18 ` Dmitry Gutov 2021-09-10 10:32 ` Lars Ingebrigtsen @ 2021-09-16 11:46 ` Filipp Gunbin 2021-09-16 11:54 ` Dmitry Gutov 2 siblings, 1 reply; 91+ messages in thread From: Filipp Gunbin @ 2021-09-16 11:46 UTC (permalink / raw) To: Juri Linkov; +Cc: 50344, Lars Ingebrigtsen, Dmitry Gutov 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. ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-09-16 11:46 ` Filipp Gunbin @ 2021-09-16 11:54 ` Dmitry Gutov 2021-09-17 15:15 ` Filipp Gunbin 0 siblings, 1 reply; 91+ messages in thread From: Dmitry Gutov @ 2021-09-16 11:54 UTC (permalink / raw) To: Filipp Gunbin, Juri Linkov; +Cc: 50344, Lars Ingebrigtsen 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. ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-09-16 11:54 ` Dmitry Gutov @ 2021-09-17 15:15 ` Filipp Gunbin 2021-09-18 0:09 ` bug#50643: " Dmitry Gutov 2021-10-05 17:43 ` Juri Linkov 0 siblings, 2 replies; 91+ messages in thread From: Filipp Gunbin @ 2021-09-17 15:15 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 50344, Lars Ingebrigtsen, Juri Linkov 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. ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50643: bug#50344: C-x v keybinding for vc-print-branch-log 2021-09-17 15:15 ` Filipp Gunbin @ 2021-09-18 0:09 ` Dmitry Gutov 2021-09-18 19:03 ` Juri Linkov 2021-10-05 17:43 ` Juri Linkov 1 sibling, 1 reply; 91+ messages in thread From: Dmitry Gutov @ 2021-09-18 0:09 UTC (permalink / raw) To: Filipp Gunbin; +Cc: 50344, Lars Ingebrigtsen, 50643, Juri Linkov 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. ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-09-18 0:09 ` bug#50643: " Dmitry Gutov @ 2021-09-18 19:03 ` Juri Linkov 2021-09-19 0:01 ` Dmitry Gutov 2021-09-20 15:59 ` bug#50643: " Filipp Gunbin 0 siblings, 2 replies; 91+ messages in thread From: Juri Linkov @ 2021-09-18 19:03 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 50344, Lars Ingebrigtsen, 50643, Filipp Gunbin >>>> 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. ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-09-18 19:03 ` Juri Linkov @ 2021-09-19 0:01 ` Dmitry Gutov 2021-09-19 17:04 ` bug#50643: " Juri Linkov 2021-09-20 15:59 ` bug#50643: " Filipp Gunbin 1 sibling, 1 reply; 91+ messages in thread From: Dmitry Gutov @ 2021-09-19 0:01 UTC (permalink / raw) To: Juri Linkov; +Cc: 50344, Lars Ingebrigtsen, 50643, Filipp Gunbin 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! ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50643: bug#50344: C-x v keybinding for vc-print-branch-log 2021-09-19 0:01 ` Dmitry Gutov @ 2021-09-19 17:04 ` Juri Linkov 2021-09-20 0:33 ` Dmitry Gutov 0 siblings, 1 reply; 91+ messages in thread From: Juri Linkov @ 2021-09-19 17:04 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 50344, Lars Ingebrigtsen, 50643, Filipp Gunbin > 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. ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-09-19 17:04 ` bug#50643: " Juri Linkov @ 2021-09-20 0:33 ` Dmitry Gutov 2021-09-20 6:49 ` bug#50643: " Juri Linkov 0 siblings, 1 reply; 91+ messages in thread From: Dmitry Gutov @ 2021-09-20 0:33 UTC (permalink / raw) To: Juri Linkov; +Cc: 50344, Lars Ingebrigtsen, 50643, Filipp Gunbin 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. ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50643: bug#50344: C-x v keybinding for vc-print-branch-log 2021-09-20 0:33 ` Dmitry Gutov @ 2021-09-20 6:49 ` Juri Linkov 2021-09-20 16:53 ` Dmitry Gutov 0 siblings, 1 reply; 91+ messages in thread From: Juri Linkov @ 2021-09-20 6:49 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 50344, Lars Ingebrigtsen, 50643, Filipp Gunbin >> 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. ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-09-20 6:49 ` bug#50643: " Juri Linkov @ 2021-09-20 16:53 ` Dmitry Gutov 2021-09-20 17:31 ` Filipp Gunbin 0 siblings, 1 reply; 91+ messages in thread From: Dmitry Gutov @ 2021-09-20 16:53 UTC (permalink / raw) To: Juri Linkov; +Cc: 50344, Lars Ingebrigtsen, 50643, Filipp Gunbin 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? ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-09-20 16:53 ` Dmitry Gutov @ 2021-09-20 17:31 ` Filipp Gunbin 0 siblings, 0 replies; 91+ messages in thread From: Filipp Gunbin @ 2021-09-20 17:31 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 50344, Lars Ingebrigtsen, 50643, Juri Linkov 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. ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50643: bug#50344: C-x v keybinding for vc-print-branch-log 2021-09-18 19:03 ` Juri Linkov 2021-09-19 0:01 ` Dmitry Gutov @ 2021-09-20 15:59 ` Filipp Gunbin 1 sibling, 0 replies; 91+ messages in thread From: Filipp Gunbin @ 2021-09-20 15:59 UTC (permalink / raw) To: Juri Linkov; +Cc: 50344, Lars Ingebrigtsen, 50643, Dmitry Gutov 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-09-17 15:15 ` Filipp Gunbin 2021-09-18 0:09 ` bug#50643: " Dmitry Gutov @ 2021-10-05 17:43 ` Juri Linkov 2021-10-06 0:37 ` Dmitry Gutov 2021-10-07 12:46 ` Filipp Gunbin 1 sibling, 2 replies; 91+ messages in thread From: Juri Linkov @ 2021-10-05 17:43 UTC (permalink / raw) To: Filipp Gunbin; +Cc: 50344, Lars Ingebrigtsen, Dmitry Gutov [-- 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 ^ permalink raw reply related [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-10-05 17:43 ` Juri Linkov @ 2021-10-06 0:37 ` Dmitry Gutov 2021-10-06 7:29 ` Juri Linkov 2021-10-06 16:28 ` Juri Linkov 2021-10-07 12:46 ` Filipp Gunbin 1 sibling, 2 replies; 91+ messages in thread From: Dmitry Gutov @ 2021-10-06 0:37 UTC (permalink / raw) To: Juri Linkov, Filipp Gunbin; +Cc: 50344, Lars Ingebrigtsen 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). ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-10-06 0:37 ` Dmitry Gutov @ 2021-10-06 7:29 ` Juri Linkov 2021-10-07 0:57 ` Dmitry Gutov 2021-10-06 16:28 ` Juri Linkov 1 sibling, 1 reply; 91+ messages in thread From: Juri Linkov @ 2021-10-06 7:29 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 50344, Lars Ingebrigtsen, Filipp Gunbin >>> 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? ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-10-06 7:29 ` Juri Linkov @ 2021-10-07 0:57 ` Dmitry Gutov 0 siblings, 0 replies; 91+ messages in thread From: Dmitry Gutov @ 2021-10-07 0:57 UTC (permalink / raw) To: Juri Linkov; +Cc: 50344, Lars Ingebrigtsen, Filipp Gunbin 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. ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-10-06 0:37 ` Dmitry Gutov 2021-10-06 7:29 ` Juri Linkov @ 2021-10-06 16:28 ` Juri Linkov 2021-10-07 0:47 ` Dmitry Gutov 1 sibling, 1 reply; 91+ messages in thread From: Juri Linkov @ 2021-10-06 16:28 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 50344, Lars Ingebrigtsen, Filipp Gunbin >>> 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. ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-10-06 16:28 ` Juri Linkov @ 2021-10-07 0:47 ` Dmitry Gutov 0 siblings, 0 replies; 91+ messages in thread From: Dmitry Gutov @ 2021-10-07 0:47 UTC (permalink / raw) To: Juri Linkov; +Cc: 50344, Lars Ingebrigtsen, Filipp Gunbin, Eric S. Raymond 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. ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-10-05 17:43 ` Juri Linkov 2021-10-06 0:37 ` Dmitry Gutov @ 2021-10-07 12:46 ` Filipp Gunbin 2021-10-07 12:55 ` Robert Pluim 2021-10-07 17:27 ` Juri Linkov 1 sibling, 2 replies; 91+ messages in thread From: Filipp Gunbin @ 2021-10-07 12:46 UTC (permalink / raw) To: Juri Linkov; +Cc: 50344, Lars Ingebrigtsen, Dmitry Gutov 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. ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-10-07 12:46 ` Filipp Gunbin @ 2021-10-07 12:55 ` Robert Pluim 2021-10-07 17:27 ` Juri Linkov 1 sibling, 0 replies; 91+ messages in thread From: Robert Pluim @ 2021-10-07 12:55 UTC (permalink / raw) To: Filipp Gunbin; +Cc: 50344, Lars Ingebrigtsen, Juri Linkov, Dmitry Gutov >>>>> 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 -- ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-10-07 12:46 ` Filipp Gunbin 2021-10-07 12:55 ` Robert Pluim @ 2021-10-07 17:27 ` Juri Linkov 1 sibling, 0 replies; 91+ messages in thread From: Juri Linkov @ 2021-10-07 17:27 UTC (permalink / raw) To: Filipp Gunbin; +Cc: 50344, Lars Ingebrigtsen, Dmitry Gutov > 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? ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-09-04 6:33 ` Lars Ingebrigtsen 2021-09-05 16:28 ` Juri Linkov @ 2021-09-08 2:50 ` Dmitry Gutov 2021-09-08 7:53 ` Lars Ingebrigtsen 1 sibling, 1 reply; 91+ messages in thread From: Dmitry Gutov @ 2021-09-08 2:50 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 50344, Juri Linkov 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. ^ permalink raw reply [flat|nested] 91+ messages in thread
* bug#50344: C-x v keybinding for vc-print-branch-log 2021-09-08 2:50 ` Dmitry Gutov @ 2021-09-08 7:53 ` Lars Ingebrigtsen 0 siblings, 0 replies; 91+ messages in thread From: Lars Ingebrigtsen @ 2021-09-08 7:53 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 50344, Juri Linkov 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
end of thread, other threads:[~2022-09-13 12:24 UTC | newest] Thread overview: 91+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2021-09-02 18:43 bug#50344: C-x v keybinding for vc-print-branch-log Juri Linkov 2021-09-02 23:24 ` Dmitry Gutov 2021-09-03 8:15 ` Juri Linkov 2021-09-03 12:26 ` Dmitry Gutov 2021-09-03 16:18 ` Juri Linkov 2021-09-03 16:41 ` Dmitry Gutov 2021-09-04 6:33 ` Lars Ingebrigtsen 2021-09-05 16:28 ` Juri Linkov 2021-09-06 8:25 ` Lars Ingebrigtsen 2021-09-06 15:19 ` Juri Linkov 2021-09-07 15:05 ` Lars Ingebrigtsen 2021-09-08 2:58 ` Dmitry Gutov 2021-09-08 8:00 ` Lars Ingebrigtsen 2021-09-08 11:59 ` Dmitry Gutov 2021-09-09 17:39 ` Juri Linkov 2021-09-09 23:18 ` Dmitry Gutov 2021-09-10 6:46 ` Juri Linkov 2021-09-10 11:27 ` Dmitry Gutov 2021-09-10 10:32 ` Lars Ingebrigtsen 2021-09-10 11:26 ` Dmitry Gutov 2021-09-13 7:47 ` Juri Linkov 2021-10-07 7:21 ` Juri Linkov 2021-10-07 7:47 ` Eli Zaretskii 2021-10-07 7:58 ` Juri Linkov 2021-10-07 8:28 ` Eli Zaretskii 2021-10-07 11:12 ` Dmitry Gutov 2021-10-07 12:56 ` Eli Zaretskii 2021-10-07 13:06 ` Dmitry Gutov 2021-10-07 13:21 ` Eli Zaretskii 2021-10-07 13:26 ` Dmitry Gutov 2021-10-07 13:50 ` Eli Zaretskii 2021-10-07 17:36 ` Juri Linkov 2021-10-07 18:22 ` Eli Zaretskii 2021-10-07 21:49 ` Dmitry Gutov 2021-10-12 12:48 ` Filipp Gunbin 2021-10-13 1:45 ` Dmitry Gutov 2021-10-13 10:12 ` Filipp Gunbin 2021-10-13 23:37 ` Dmitry Gutov 2021-12-24 11:56 ` Philip Kaludercic 2021-12-24 12:03 ` Dmitry Gutov 2021-12-24 13:57 ` Philip Kaludercic 2021-12-24 23:45 ` Dmitry Gutov 2021-12-25 11:37 ` Philip Kaludercic 2021-12-25 12:08 ` Dmitry Gutov 2022-09-09 5:46 ` Sean Whitton 2022-09-09 6:29 ` Juri Linkov 2022-09-09 17:09 ` Lars Ingebrigtsen 2022-09-11 15:10 ` Juri Linkov 2022-09-11 15:25 ` Lars Ingebrigtsen 2022-09-12 18:07 ` Juri Linkov 2022-09-12 18:21 ` Eli Zaretskii 2022-09-12 19:13 ` Juri Linkov 2022-09-13 12:24 ` Eli Zaretskii 2022-09-12 18:57 ` Sean Whitton 2021-10-07 13:11 ` Robert Pluim 2021-10-07 13:51 ` Filipp Gunbin 2021-10-07 9:57 ` Gregory Heytings 2021-10-07 11:14 ` Dmitry Gutov 2021-10-07 11:25 ` Gregory Heytings 2021-10-07 11:35 ` Dmitry Gutov 2021-10-07 11:42 ` Gregory Heytings 2021-10-07 12:25 ` Kévin Le Gouguec 2021-10-07 12:42 ` Filipp Gunbin 2021-10-07 12:53 ` Dmitry Gutov 2021-10-07 13:11 ` Eli Zaretskii 2021-10-07 12:51 ` Eli Zaretskii 2021-10-07 17:30 ` Juri Linkov 2021-10-07 18:25 ` Eli Zaretskii 2021-09-16 11:46 ` Filipp Gunbin 2021-09-16 11:54 ` Dmitry Gutov 2021-09-17 15:15 ` Filipp Gunbin 2021-09-18 0:09 ` bug#50643: " Dmitry Gutov 2021-09-18 19:03 ` Juri Linkov 2021-09-19 0:01 ` Dmitry Gutov 2021-09-19 17:04 ` bug#50643: " Juri Linkov 2021-09-20 0:33 ` Dmitry Gutov 2021-09-20 6:49 ` bug#50643: " Juri Linkov 2021-09-20 16:53 ` Dmitry Gutov 2021-09-20 17:31 ` Filipp Gunbin 2021-09-20 15:59 ` bug#50643: " Filipp Gunbin 2021-10-05 17:43 ` Juri Linkov 2021-10-06 0:37 ` Dmitry Gutov 2021-10-06 7:29 ` Juri Linkov 2021-10-07 0:57 ` Dmitry Gutov 2021-10-06 16:28 ` Juri Linkov 2021-10-07 0:47 ` Dmitry Gutov 2021-10-07 12:46 ` Filipp Gunbin 2021-10-07 12:55 ` Robert Pluim 2021-10-07 17:27 ` Juri Linkov 2021-09-08 2:50 ` Dmitry Gutov 2021-09-08 7:53 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.