* bug#23436: [PATCH] Use the true name of a file to determine responsible vc. @ 2016-05-03 21:32 Hong Xu 2016-10-19 19:19 ` Hong Xu 0 siblings, 1 reply; 31+ messages in thread From: Hong Xu @ 2016-05-03 21:32 UTC (permalink / raw) To: 23436; +Cc: Hong Xu In many cases, e.g., a symbolic link to a directory inside a vc tracked directory, vc-responsible-backend would fail to know the true backend. --- There is probably a better fix than this... Feel free to do so. --- lisp/vc/vc.el | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/lisp/vc/vc.el b/lisp/vc/vc.el index 25b41e34e645..1b060b4d1374 100644 --- a/lisp/vc/vc.el +++ b/lisp/vc/vc.el @@ -960,14 +960,15 @@ If FILE is already registered, return the backend of FILE. If FILE is not registered, then the first backend in `vc-handled-backends' that declares itself responsible for FILE is returned." - (or (and (not (file-directory-p file)) (vc-backend file)) + (let ((file-path (file-truename file))) + (or (and (not (file-directory-p file-path)) (vc-backend file-path)) (catch 'found - ;; First try: find a responsible backend. If this is for registration, - ;; it must be a backend under which FILE is not yet registered. - (dolist (backend vc-handled-backends) - (and (vc-call-backend backend 'responsible-p file) - (throw 'found backend)))) - (error "No VC backend is responsible for %s" file))) + ;; First try: find a responsible backend. If this is for registration, + ;; it must be a backend under which FILE is not yet registered. + (dolist (backend vc-handled-backends) + (and (vc-call-backend backend 'responsible-p file-path) + (throw 'found backend)))) + (error "No VC backend is responsible for %s" file-path)))) (defun vc-expand-dirs (file-or-dir-list backend) "Expands directories in a file list specification. -- 2.8.2 ^ permalink raw reply related [flat|nested] 31+ messages in thread
* bug#23436: [PATCH] Use the true name of a file to determine responsible vc. 2016-05-03 21:32 bug#23436: [PATCH] Use the true name of a file to determine responsible vc Hong Xu @ 2016-10-19 19:19 ` Hong Xu 2016-10-19 19:33 ` bug#23436: [PATCH] Attemp to use the true name of a file to determine responsible vc if the genuine name does not work Hong Xu 0 siblings, 1 reply; 31+ messages in thread From: Hong Xu @ 2016-10-19 19:19 UTC (permalink / raw) To: 23436 [-- Attachment #1.1.1: Type: text/plain, Size: 1856 bytes --] A better version of the fix is attached. On 05/03/2016 02:32 PM, Hong Xu wrote: > In many cases, e.g., a symbolic link to a directory inside a vc tracked > directory, vc-responsible-backend would fail to know the true backend. > > --- > > There is probably a better fix than this... Feel free to do so. > > --- > lisp/vc/vc.el | 15 ++++++++------- > 1 file changed, 8 insertions(+), 7 deletions(-) > > diff --git a/lisp/vc/vc.el b/lisp/vc/vc.el > index 25b41e34e645..1b060b4d1374 100644 > --- a/lisp/vc/vc.el > +++ b/lisp/vc/vc.el > @@ -960,14 +960,15 @@ If FILE is already registered, return the > backend of FILE. If FILE is not registered, then the > first backend in `vc-handled-backends' that declares itself > responsible for FILE is returned." > - (or (and (not (file-directory-p file)) (vc-backend file)) > + (let ((file-path (file-truename file))) > + (or (and (not (file-directory-p file-path)) (vc-backend file-path)) > (catch 'found > - ;; First try: find a responsible backend. If this is for registration, > - ;; it must be a backend under which FILE is not yet registered. > - (dolist (backend vc-handled-backends) > - (and (vc-call-backend backend 'responsible-p file) > - (throw 'found backend)))) > - (error "No VC backend is responsible for %s" file))) > + ;; First try: find a responsible backend. If this is for registration, > + ;; it must be a backend under which FILE is not yet registered. > + (dolist (backend vc-handled-backends) > + (and (vc-call-backend backend 'responsible-p file-path) > + (throw 'found backend)))) > + (error "No VC backend is responsible for %s" file-path)))) > > (defun vc-expand-dirs (file-or-dir-list backend) > "Expands directories in a file list specification. > [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1.1.2: vc.patch --] [-- Type: text/x-patch; name="vc.patch", Size: 813 bytes --] diff --git a/lisp/vc/vc.el b/lisp/vc/vc.el index af875e89907f..368c89fb2557 100644 --- a/lisp/vc/vc.el +++ b/lisp/vc/vc.el @@ -964,9 +964,10 @@ vc-responsible-backend (catch 'found ;; First try: find a responsible backend. If this is for registration, ;; it must be a backend under which FILE is not yet registered. - (dolist (backend vc-handled-backends) - (and (vc-call-backend backend 'responsible-p file) - (throw 'found backend)))) + (dolist (file-path (list file (file-truename file))) + (dolist (backend vc-handled-backends) + (and (vc-call-backend backend 'responsible-p file-path) + (throw 'found backend))))) (error "No VC backend is responsible for %s" file))) (defun vc-expand-dirs (file-or-dir-list backend) [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply related [flat|nested] 31+ messages in thread
* bug#23436: [PATCH] Attemp to use the true name of a file to determine responsible vc if the genuine name does not work. 2016-10-19 19:19 ` Hong Xu @ 2016-10-19 19:33 ` Hong Xu 2016-10-19 23:37 ` Dmitry Gutov 0 siblings, 1 reply; 31+ messages in thread From: Hong Xu @ 2016-10-19 19:33 UTC (permalink / raw) To: 23436 [-- Attachment #1.1.1: Type: text/plain, Size: 28 bytes --] Another updated version... [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1.1.2: vc.patch --] [-- Type: text/x-patch; name="vc.patch", Size: 1082 bytes --] diff --git a/lisp/vc/vc.el b/lisp/vc/vc.el index af875e89907f..db9b0db39c6b 100644 --- a/lisp/vc/vc.el +++ b/lisp/vc/vc.el @@ -962,11 +962,13 @@ vc-responsible-backend responsible for FILE is returned." (or (and (not (file-directory-p file)) (vc-backend file)) (catch 'found - ;; First try: find a responsible backend. If this is for registration, - ;; it must be a backend under which FILE is not yet registered. - (dolist (backend vc-handled-backends) - (and (vc-call-backend backend 'responsible-p file) - (throw 'found backend)))) + ;; First try: find a responsible backend. If this is for + ;; registration, it must be a backend under which FILE is not + ;; yet registered. + (dolist (file-path (list file (file-truename file))) + (dolist (backend vc-handled-backends) + (and (vc-call-backend backend 'responsible-p file-path) + (throw 'found backend))))) (error "No VC backend is responsible for %s" file))) (defun vc-expand-dirs (file-or-dir-list backend) [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply related [flat|nested] 31+ messages in thread
* bug#23436: [PATCH] Attemp to use the true name of a file to determine responsible vc if the genuine name does not work. 2016-10-19 19:33 ` bug#23436: [PATCH] Attemp to use the true name of a file to determine responsible vc if the genuine name does not work Hong Xu @ 2016-10-19 23:37 ` Dmitry Gutov 2016-10-19 23:49 ` Hong Xu 0 siblings, 1 reply; 31+ messages in thread From: Dmitry Gutov @ 2016-10-19 23:37 UTC (permalink / raw) To: Hong Xu, 23436 On 19.10.2016 22:33, Hong Xu wrote: > + (dolist (file-path (list file (file-truename file))) Why not just use the true name? ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#23436: [PATCH] Attemp to use the true name of a file to determine responsible vc if the genuine name does not work. 2016-10-19 23:37 ` Dmitry Gutov @ 2016-10-19 23:49 ` Hong Xu 2016-10-19 23:58 ` Dmitry Gutov 0 siblings, 1 reply; 31+ messages in thread From: Hong Xu @ 2016-10-19 23:49 UTC (permalink / raw) To: Dmitry Gutov, 23436 [-- Attachment #1.1: Type: text/plain, Size: 332 bytes --] On 10/19/2016 04:37 PM, Dmitry Gutov wrote: > On 19.10.2016 22:33, Hong Xu wrote: >> + (dolist (file-path (list file (file-truename file))) > > Why not just use the true name? Because sometimes we track symlinks specifically. The symlink files may link to a file in a different repo, for example a git submodule. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#23436: [PATCH] Attemp to use the true name of a file to determine responsible vc if the genuine name does not work. 2016-10-19 23:49 ` Hong Xu @ 2016-10-19 23:58 ` Dmitry Gutov 2016-10-20 0:16 ` Hong Xu 0 siblings, 1 reply; 31+ messages in thread From: Dmitry Gutov @ 2016-10-19 23:58 UTC (permalink / raw) To: Hong Xu, 23436 On 20.10.2016 02:49, Hong Xu wrote: > On 10/19/2016 04:37 PM, Dmitry Gutov wrote: >> On 19.10.2016 22:33, Hong Xu wrote: >>> + (dolist (file-path (list file (file-truename file))) >> >> Why not just use the true name? > > Because sometimes we track symlinks specifically. The symlink files may > link to a file in a different repo, for example a git submodule. I'm not sure I understand. Please outline a problem scenario. ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#23436: [PATCH] Attemp to use the true name of a file to determine responsible vc if the genuine name does not work. 2016-10-19 23:58 ` Dmitry Gutov @ 2016-10-20 0:16 ` Hong Xu 2016-10-20 6:58 ` Eli Zaretskii 2016-10-20 9:47 ` Dmitry Gutov 0 siblings, 2 replies; 31+ messages in thread From: Hong Xu @ 2016-10-20 0:16 UTC (permalink / raw) To: Dmitry Gutov, 23436 [-- Attachment #1.1: Type: text/plain, Size: 826 bytes --] On 10/19/2016 04:58 PM, Dmitry Gutov wrote: > On 20.10.2016 02:49, Hong Xu wrote: >> On 10/19/2016 04:37 PM, Dmitry Gutov wrote: >>> On 19.10.2016 22:33, Hong Xu wrote: >>>> + (dolist (file-path (list file (file-truename file))) >>> >>> Why not just use the true name? >> >> Because sometimes we track symlinks specifically. The symlink files may >> link to a file in a different repo, for example a git submodule. > > I'm not sure I understand. Please outline a problem scenario. mkdir my-repo && cd my-repo hg init git clone git://git.savannah.gnu.org/emacs.git ln -s emacs/README README_emacs hg add README_emacs README_emacs is tracked in the repo "my-repo" but README is tracked in the emacs repo. If true name is directly used, we would fail to obtain the correct responsible backend. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#23436: [PATCH] Attemp to use the true name of a file to determine responsible vc if the genuine name does not work. 2016-10-20 0:16 ` Hong Xu @ 2016-10-20 6:58 ` Eli Zaretskii 2016-10-20 7:21 ` Hong Xu 2016-10-20 9:47 ` Dmitry Gutov 1 sibling, 1 reply; 31+ messages in thread From: Eli Zaretskii @ 2016-10-20 6:58 UTC (permalink / raw) To: Hong Xu; +Cc: dgutov, 23436 > From: Hong Xu <hong@topbug.net> > Date: Wed, 19 Oct 2016 17:16:58 -0700 > > >>>> + (dolist (file-path (list file (file-truename file))) > >>> > >>> Why not just use the true name? > >> > >> Because sometimes we track symlinks specifically. The symlink files may > >> link to a file in a different repo, for example a git submodule. > > > > I'm not sure I understand. Please outline a problem scenario. > > mkdir my-repo && cd my-repo > hg init > git clone git://git.savannah.gnu.org/emacs.git > ln -s emacs/README README_emacs > hg add README_emacs > > README_emacs is tracked in the repo "my-repo" but README is tracked in > the emacs repo. If true name is directly used, we would fail to obtain > the correct responsible backend. What is the correct backend in this case? You seem to assume it's the one that maintains the symlink, but why is that assumption true? The backend is determined for certain operations. Did you make sure all of them will indeed want the backend of my-repo and not the other one. And what is the semantics of such a situation, anyway? ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#23436: [PATCH] Attemp to use the true name of a file to determine responsible vc if the genuine name does not work. 2016-10-20 6:58 ` Eli Zaretskii @ 2016-10-20 7:21 ` Hong Xu 2016-10-20 8:23 ` Eli Zaretskii 0 siblings, 1 reply; 31+ messages in thread From: Hong Xu @ 2016-10-20 7:21 UTC (permalink / raw) To: Eli Zaretskii; +Cc: dgutov, 23436 [-- Attachment #1.1: Type: text/plain, Size: 1885 bytes --] On 10/19/2016 11:58 PM, Eli Zaretskii wrote: >> From: Hong Xu <hong@topbug.net> >> Date: Wed, 19 Oct 2016 17:16:58 -0700 >> >>>>>> + (dolist (file-path (list file (file-truename file))) >>>>> >>>>> Why not just use the true name? >>>> >>>> Because sometimes we track symlinks specifically. The symlink files may >>>> link to a file in a different repo, for example a git submodule. >>> >>> I'm not sure I understand. Please outline a problem scenario. >> >> mkdir my-repo && cd my-repo >> hg init >> git clone git://git.savannah.gnu.org/emacs.git >> ln -s emacs/README README_emacs >> hg add README_emacs >> >> README_emacs is tracked in the repo "my-repo" but README is tracked in >> the emacs repo. If true name is directly used, we would fail to obtain >> the correct responsible backend. > > What is the correct backend in this case? You seem to assume it's the > one that maintains the symlink, but why is that assumption true? > > The backend is determined for certain operations. Did you make sure > all of them will indeed want the backend of my-repo and not the other > one. I agree that this assumption is quite controversial even for myself -- it depends on what this function is used for. Adding an option may be the best way to resolve it. > And what is the semantics of such a situation, anyway? For example, one may manage the home directory configuration with one type of VC. For configuration files for some applications, she may rarely use them, so she simply cloned/checked out someone else's configuration using a different VC, and symlink the file in the home dir to the actual configuration file. Another example: one may have a repository that contains files linking to non-tracked files -- create a repository that link to common configuration files such as the ones in /etc for easier management. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#23436: [PATCH] Attemp to use the true name of a file to determine responsible vc if the genuine name does not work. 2016-10-20 7:21 ` Hong Xu @ 2016-10-20 8:23 ` Eli Zaretskii 2016-10-20 8:50 ` Dmitry Gutov 2016-10-20 9:46 ` Andreas Schwab 0 siblings, 2 replies; 31+ messages in thread From: Eli Zaretskii @ 2016-10-20 8:23 UTC (permalink / raw) To: Hong Xu; +Cc: dgutov, 23436 > Cc: dgutov@yandex.ru, 23436@debbugs.gnu.org > From: Hong Xu <hong@topbug.net> > Date: Thu, 20 Oct 2016 00:21:31 -0700 > > On 10/19/2016 11:58 PM, Eli Zaretskii wrote: > >> From: Hong Xu <hong@topbug.net> > >> Date: Wed, 19 Oct 2016 17:16:58 -0700 > >> > >>>>>> + (dolist (file-path (list file (file-truename file))) > >>>>> > >>>>> Why not just use the true name? > >>>> > >>>> Because sometimes we track symlinks specifically. The symlink files may > >>>> link to a file in a different repo, for example a git submodule. > >>> > >>> I'm not sure I understand. Please outline a problem scenario. > >> > >> mkdir my-repo && cd my-repo > >> hg init > >> git clone git://git.savannah.gnu.org/emacs.git > >> ln -s emacs/README README_emacs > >> hg add README_emacs > >> > >> README_emacs is tracked in the repo "my-repo" but README is tracked in > >> the emacs repo. If true name is directly used, we would fail to obtain > >> the correct responsible backend. > > > > What is the correct backend in this case? You seem to assume it's the > > one that maintains the symlink, but why is that assumption true? > > > > The backend is determined for certain operations. Did you make sure > > all of them will indeed want the backend of my-repo and not the other > > one. > > I agree that this assumption is quite controversial even for myself -- > it depends on what this function is used for. Adding an option may be > the best way to resolve it. What bothers me is that the use case where there really is no backend will now take twice as much time as it did before. Can we avoid trying the 2nd search by detecting that the truename and the original name specify the same file? Or maybe by detecting the file types that could justify the second search in the first place? ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#23436: [PATCH] Attemp to use the true name of a file to determine responsible vc if the genuine name does not work. 2016-10-20 8:23 ` Eli Zaretskii @ 2016-10-20 8:50 ` Dmitry Gutov 2016-10-20 9:46 ` Andreas Schwab 1 sibling, 0 replies; 31+ messages in thread From: Dmitry Gutov @ 2016-10-20 8:50 UTC (permalink / raw) To: Eli Zaretskii, Hong Xu; +Cc: 23436 On 20.10.2016 11:23, Eli Zaretskii wrote: > What bothers me is that the use case where there really is no backend > will now take twice as much time as it did before. That is my main concern as well. ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#23436: [PATCH] Attemp to use the true name of a file to determine responsible vc if the genuine name does not work. 2016-10-20 8:23 ` Eli Zaretskii 2016-10-20 8:50 ` Dmitry Gutov @ 2016-10-20 9:46 ` Andreas Schwab 2016-10-20 10:02 ` Eli Zaretskii 1 sibling, 1 reply; 31+ messages in thread From: Andreas Schwab @ 2016-10-20 9:46 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Hong Xu, 23436, dgutov On Okt 20 2016, Eli Zaretskii <eliz@gnu.org> wrote: > What bothers me is that the use case where there really is no backend > will now take twice as much time as it did before. Perhaps only do that if the file is a symlink? Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#23436: [PATCH] Attemp to use the true name of a file to determine responsible vc if the genuine name does not work. 2016-10-20 9:46 ` Andreas Schwab @ 2016-10-20 10:02 ` Eli Zaretskii 2016-10-20 10:58 ` Eli Zaretskii 0 siblings, 1 reply; 31+ messages in thread From: Eli Zaretskii @ 2016-10-20 10:02 UTC (permalink / raw) To: Andreas Schwab; +Cc: hong, 23436, dgutov > From: Andreas Schwab <schwab@suse.de> > Cc: Hong Xu <hong@topbug.net>, dgutov@yandex.ru, 23436@debbugs.gnu.org > Date: Thu, 20 Oct 2016 11:46:50 +0200 > > On Okt 20 2016, Eli Zaretskii <eliz@gnu.org> wrote: > > > What bothers me is that the use case where there really is no backend > > will now take twice as much time as it did before. > > Perhaps only do that if the file is a symlink? Something like that, yes. Wouldn't a hard link also be a candidate? Are there any others? ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#23436: [PATCH] Attemp to use the true name of a file to determine responsible vc if the genuine name does not work. 2016-10-20 10:02 ` Eli Zaretskii @ 2016-10-20 10:58 ` Eli Zaretskii 0 siblings, 0 replies; 31+ messages in thread From: Eli Zaretskii @ 2016-10-20 10:58 UTC (permalink / raw) To: schwab, hong; +Cc: 23436, dgutov > Date: Thu, 20 Oct 2016 13:02:51 +0300 > From: Eli Zaretskii <eliz@gnu.org> > Cc: hong@topbug.net, 23436@debbugs.gnu.org, dgutov@yandex.ru > > > > What bothers me is that the use case where there really is no backend > > > will now take twice as much time as it did before. > > > > Perhaps only do that if the file is a symlink? > > Something like that, yes. Wouldn't a hard link also be a candidate? > Are there any others? Actually, I think the symlink case is the only one we should care about, as long as we use file-truename. So yes, doing the second test only for symlink sounds like the way to avoid doubling the search time. Thanks. ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#23436: [PATCH] Attemp to use the true name of a file to determine responsible vc if the genuine name does not work. 2016-10-20 0:16 ` Hong Xu 2016-10-20 6:58 ` Eli Zaretskii @ 2016-10-20 9:47 ` Dmitry Gutov 2016-10-20 16:39 ` Hong Xu 1 sibling, 1 reply; 31+ messages in thread From: Dmitry Gutov @ 2016-10-20 9:47 UTC (permalink / raw) To: Hong Xu, 23436 On 20.10.2016 03:16, Hong Xu wrote: > mkdir my-repo && cd my-repo > hg init > git clone git://git.savannah.gnu.org/emacs.git > ln -s emacs/README README_emacs > hg add README_emacs > > README_emacs is tracked in the repo "my-repo" but README is tracked in > the emacs repo. If true name is directly used, we would fail to obtain > the correct responsible backend. OK, thanks. Regarding the user option, though, wouldn't it be almost as good if you could call vc-follow-link interactively? Not sure if vc-follow-link works for directories, but a new command could. ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#23436: [PATCH] Attemp to use the true name of a file to determine responsible vc if the genuine name does not work. 2016-10-20 9:47 ` Dmitry Gutov @ 2016-10-20 16:39 ` Hong Xu 2016-10-20 22:34 ` Dmitry Gutov 0 siblings, 1 reply; 31+ messages in thread From: Hong Xu @ 2016-10-20 16:39 UTC (permalink / raw) To: Dmitry Gutov, 23436 [-- Attachment #1.1: Type: text/plain, Size: 909 bytes --] On 10/20/2016 02:47 AM, Dmitry Gutov wrote: > On 20.10.2016 03:16, Hong Xu wrote: > >> mkdir my-repo && cd my-repo >> hg init >> git clone git://git.savannah.gnu.org/emacs.git >> ln -s emacs/README README_emacs >> hg add README_emacs >> >> README_emacs is tracked in the repo "my-repo" but README is tracked in >> the emacs repo. If true name is directly used, we would fail to obtain >> the correct responsible backend. > > OK, thanks. > > Regarding the user option, though, wouldn't it be almost as good if you > could call vc-follow-link interactively? Not sure if vc-follow-link > works for directories, but a new command could. Regarding the performance and user options, this might be the best way (or consider adding a function that wraps the two calls). If this is the way to go, can you add a little explanation in the doc string? People may not be aware of it. Thanks. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#23436: [PATCH] Attemp to use the true name of a file to determine responsible vc if the genuine name does not work. 2016-10-20 16:39 ` Hong Xu @ 2016-10-20 22:34 ` Dmitry Gutov 2016-10-20 23:04 ` Hong Xu 0 siblings, 1 reply; 31+ messages in thread From: Dmitry Gutov @ 2016-10-20 22:34 UTC (permalink / raw) To: Hong Xu, 23436 On 20.10.2016 19:39, Hong Xu wrote: > Regarding the performance and user options, this might be the best way > (or consider adding a function that wraps the two calls). If this is the > way to go, can you add a little explanation in the doc string? People > may not be aware of it. Thanks. Sorry, what might be the best way? A new command? What would you like to see clarified in its docstring? ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#23436: [PATCH] Attemp to use the true name of a file to determine responsible vc if the genuine name does not work. 2016-10-20 22:34 ` Dmitry Gutov @ 2016-10-20 23:04 ` Hong Xu 2016-10-24 23:41 ` Dmitry Gutov 0 siblings, 1 reply; 31+ messages in thread From: Hong Xu @ 2016-10-20 23:04 UTC (permalink / raw) To: Dmitry Gutov, 23436 [-- Attachment #1.1: Type: text/plain, Size: 859 bytes --] On 10/20/2016 03:34 PM, Dmitry Gutov wrote: > On 20.10.2016 19:39, Hong Xu wrote: > >> Regarding the performance and user options, this might be the best way >> (or consider adding a function that wraps the two calls). If this is the >> way to go, can you add a little explanation in the doc string? People >> may not be aware of it. Thanks. > > Sorry, what might be the best way? A new command? What would you like to > see clarified in its docstring? Sorry for the confusion. Either keeping what it was or adding a new command [which essentially calls (vc-responsible-backend (vc-follow-link file)) ] would be the best option regarding performance. e need to clarify that symlinks are not followed in vc-responsible-backend, and If the first option is adopted, mention that vc-follow-link should be used if link following is desired. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#23436: [PATCH] Attemp to use the true name of a file to determine responsible vc if the genuine name does not work. 2016-10-20 23:04 ` Hong Xu @ 2016-10-24 23:41 ` Dmitry Gutov 2016-10-25 19:05 ` Hong Xu 0 siblings, 1 reply; 31+ messages in thread From: Dmitry Gutov @ 2016-10-24 23:41 UTC (permalink / raw) To: Hong Xu, 23436 On 21.10.2016 02:04, Hong Xu wrote: > Sorry for the confusion. Either keeping what it was or adding a new > command [which essentially calls (vc-responsible-backend (vc-follow-link > file)) ] would be the best option regarding performance. Shouldn't the command call find-alternate-file instead? Then you can continue working with buffer-file-name and default-directory inside the symlink target directory. And if you visit any nearby files there, you won't have to call the vc-follow-link for each of them again? What are the downsides to this approach? > e need to > clarify that symlinks are not followed in vc-responsible-backend, and If > the first option is adopted, mention that vc-follow-link should be used > if link following is desired. OK, mention where? ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#23436: [PATCH] Attemp to use the true name of a file to determine responsible vc if the genuine name does not work. 2016-10-24 23:41 ` Dmitry Gutov @ 2016-10-25 19:05 ` Hong Xu 2016-10-25 23:12 ` Dmitry Gutov 0 siblings, 1 reply; 31+ messages in thread From: Hong Xu @ 2016-10-25 19:05 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 23436 [-- Attachment #1: Type: text/plain, Size: 1243 bytes --] On Mon, Oct 24 2016, Dmitry Gutov <dgutov@yandex.ru> wrote: > On 21.10.2016 02:04, Hong Xu wrote: > >> Sorry for the confusion. Either keeping what it was or adding a new >> command [which essentially calls (vc-responsible-backend (vc-follow-link >> file)) ] would be the best option regarding performance. > > Shouldn't the command call find-alternate-file instead? Then you can > continue working with buffer-file-name and default-directory inside the > symlink target directory. And if you visit any nearby files there, you > won't have to call the vc-follow-link for each of them again? > > What are the downsides to this approach? I don't understand why find-alternate-file should be used. The reason we used (vc-follow-link) is to pass the correct file path to vc-responsible-backend. I don't see how find-alternate-file can be used here. > >> e need to >> clarify that symlinks are not followed in vc-responsible-backend, and If >> the first option is adopted, mention that vc-follow-link should be used >> if link following is desired. > > OK, mention where? In the doc string. Maybe we should also mention `vc-responsible-backend' in the info doc "Supported Version Control Systems" in general. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 818 bytes --] ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#23436: [PATCH] Attemp to use the true name of a file to determine responsible vc if the genuine name does not work. 2016-10-25 19:05 ` Hong Xu @ 2016-10-25 23:12 ` Dmitry Gutov 2016-10-30 0:42 ` Hong Xu 0 siblings, 1 reply; 31+ messages in thread From: Dmitry Gutov @ 2016-10-25 23:12 UTC (permalink / raw) To: Hong Xu; +Cc: 23436 On 25.10.2016 22:05, Hong Xu wrote: > I don't understand why find-alternate-file should be used. For no reason other than the resulting command could be useful in more situations than just this one. > The reason we > used (vc-follow-link) is to pass the correct file path to > vc-responsible-backend. I don't see how find-alternate-file can be used here. It would open the file (or directory) than is the true name of the currently visited file (or directory), and kill the previous buffer. vc-responsible-backend would be called with the true name automatically. This is close to what vc-follow-link does already. But if that's definitely not what you want, how about a command like this? (defun vc-refresh-as-link-target () (interactive) (let ((buffer-file-name (file-truename buffer-file-name))) (vc-refresh-state))) By the way, please remind us why vc-follow-symlinks (the variable) with the default value `ask' is not sufficient for you? >> OK, mention where? > > In the doc string. The docstring of what? Please be more precise, the less I have to think about or make choices regarding documentation, the happier I am. > Maybe we should also mention `vc-responsible-backend' > in the info doc "Supported Version Control Systems" in general. Care to send the proposed addition in the form of a patch? ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#23436: [PATCH] Attemp to use the true name of a file to determine responsible vc if the genuine name does not work. 2016-10-25 23:12 ` Dmitry Gutov @ 2016-10-30 0:42 ` Hong Xu 2016-10-30 16:21 ` Eli Zaretskii 2016-10-31 11:34 ` Dmitry Gutov 0 siblings, 2 replies; 31+ messages in thread From: Hong Xu @ 2016-10-30 0:42 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 23436 [-- Attachment #1.1: Type: text/plain, Size: 1982 bytes --] On 2016-10-25 Tue 16:12 GMT-0700, Dmitry Gutov <dgutov@yandex.ru> wrote: > On 25.10.2016 22:05, Hong Xu wrote: > >> I don't understand why find-alternate-file should be used. > > For no reason other than the resulting command could be useful in more > situations than just this one. > >> The reason we >> used (vc-follow-link) is to pass the correct file path to >> vc-responsible-backend. I don't see how find-alternate-file can be used here. > > It would open the file (or directory) than is the true name of the > currently visited file (or directory), and kill the previous buffer. > > vc-responsible-backend would be called with the true name automatically. > This is close to what vc-follow-link does already. > > But if that's definitely not what you want, how about a command like this? > > (defun vc-refresh-as-link-target () > (interactive) > (let ((buffer-file-name (file-truename buffer-file-name))) > (vc-refresh-state))) > > By the way, please remind us why vc-follow-symlinks (the variable) with > the default value `ask' is not sufficient for you? OK, I think I have screwed it up. vc-responsible-backend looks like a function mainly provided for elisp programming purpose, which people can make use in their own customization. Thus, none of these functions should be used. Instead, file-truename or file-chase-links should be used. That is, (vc-responsible-backend (file-chase-links file)) > >>> OK, mention where? >> >> In the doc string. > > The docstring of what? Please be more precise, the less I have to think > about or make choices regarding documentation, the happier I am. > >> Maybe we should also mention `vc-responsible-backend' >> in the info doc "Supported Version Control Systems" in general. > > Care to send the proposed addition in the form of a patch? The attachment is a draft of my proposed doc change. Feel free to adjust the contents and the language. Hong [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1.2: vc-doc.patch --] [-- Type: text/x-diff, Size: 2202 bytes --] diff --git a/doc/emacs/maintaining.texi b/doc/emacs/maintaining.texi index aca29910b7d3..8f31fa168c23 100644 --- a/doc/emacs/maintaining.texi +++ b/doc/emacs/maintaining.texi @@ -223,7 +223,7 @@ Version Control Systems @cindex SRC @cindex src @item -SRC (src) is RCS, reloaded - a specialized version-control system +SRC (src) is RCS, reloaded---a specialized version-control system designed for single-file projects worked on by only one person. It allows multiple files with independent version-control histories to exist in one directory, and is thus particularly well suited for @@ -233,6 +233,22 @@ Version Control Systems supports almost all SRC operations. @end itemize +@defun vc-responsible-backend file +This function can be used to determine the responsible VC backend of +the given file path @var{file}. For example, if @code{emacs.c} is a +file tracked by git, @code{(vc-responsible-backend "emacs.c")} returns +@code{"Git"}. Note that if @var{file} is a symbolic link, +@code{vc-responsible-backend} will not resolve it---it always reports +the backend of the symbolic link file itself. Instead, to get the +backend VC of the file to which @var{file} refers, wrap @var{file} +with a symbolic link resolving function such as +@code{file-chase-links}: + +@smallexample +(vc-responsible-backend (file-chase-links "emacs.c")) +@end smallexample +@end defun + @node VCS Concepts @subsubsection Concepts of Version Control diff --git a/lisp/vc/vc.el b/lisp/vc/vc.el index ac020d095397..a1e4388f6e5c 100644 --- a/lisp/vc/vc.el +++ b/lisp/vc/vc.el @@ -959,7 +959,11 @@ vc-responsible-backend If FILE is already registered, return the backend of FILE. If FILE is not registered, then the first backend in `vc-handled-backends' that declares itself -responsible for FILE is returned." +responsible for FILE is returned. + +Note that if FILE is a symbolic link, it will not be resolved -- +it will report the responsible backend system for the symbolic +link itself." (or (and (not (file-directory-p file)) (vc-backend file)) (catch 'found ;; First try: find a responsible backend. If this is for registration, [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 818 bytes --] ^ permalink raw reply related [flat|nested] 31+ messages in thread
* bug#23436: [PATCH] Attemp to use the true name of a file to determine responsible vc if the genuine name does not work. 2016-10-30 0:42 ` Hong Xu @ 2016-10-30 16:21 ` Eli Zaretskii 2016-10-30 22:50 ` Hong Xu 2016-10-31 11:34 ` Dmitry Gutov 1 sibling, 1 reply; 31+ messages in thread From: Eli Zaretskii @ 2016-10-30 16:21 UTC (permalink / raw) To: Hong Xu; +Cc: dgutov, 23436 > From: Hong Xu <hong@topbug.net> > Date: Sat, 29 Oct 2016 17:42:01 -0700 > Cc: 23436@debbugs.gnu.org > > The attachment is a draft of my proposed doc change. Feel free to adjust > the contents and the language. Thanks, see a few comments below. > diff --git a/doc/emacs/maintaining.texi b/doc/emacs/maintaining.texi > index aca29910b7d3..8f31fa168c23 100644 > --- a/doc/emacs/maintaining.texi > +++ b/doc/emacs/maintaining.texi This should go to the ELisp manual, not the Emacs User manual. > +@defun vc-responsible-backend file > +This function can be used to determine the responsible VC backend of > +the given file path @var{file}. GNU coding standards frown on using "path" for anything that isn't a PATH-style list of directories. We use "file name" instead, but in this case you don't need even that: just say "the given @var{file}". > For example, if @code{emacs.c} is a emacs.c is a file, so it should have the @file markup, not @code. > +file tracked by git, @code{(vc-responsible-backend "emacs.c")} returns > +@code{"Git"}. ^^^^^^^^^^^^ You want @samp{Git} here, without the quotes. The quotes might mislead someone into thinking the result is a string. Last, but not least: documentation changes need ChangeLog-style commit log messages as well (just use "C-x 4 a" to get a preformatted skeleton from which you could start). ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#23436: [PATCH] Attemp to use the true name of a file to determine responsible vc if the genuine name does not work. 2016-10-30 16:21 ` Eli Zaretskii @ 2016-10-30 22:50 ` Hong Xu 2016-10-31 15:43 ` Eli Zaretskii 0 siblings, 1 reply; 31+ messages in thread From: Hong Xu @ 2016-10-30 22:50 UTC (permalink / raw) To: Eli Zaretskii; +Cc: dgutov, 23436 [-- Attachment #1.1: Type: text/plain, Size: 1771 bytes --] On 2016-10-30 Sun 09:21 GMT-0700, Eli Zaretskii <eliz@gnu.org> wrote: >> diff --git a/doc/emacs/maintaining.texi b/doc/emacs/maintaining.texi >> index aca29910b7d3..8f31fa168c23 100644 >> --- a/doc/emacs/maintaining.texi >> +++ b/doc/emacs/maintaining.texi > > This should go to the ELisp manual, not the Emacs User manual. > I don't know how to resolve this issue: there seems no proper place to insert the defun section. I'm gonna leave my updated version of the defun section here in this email, and updated all other parts in the new version of the patch (as attached). You may decide where to put this part. --------------------- vc-responsible-backend defun ------------------------- @defun vc-responsible-backend file This function can be used to determine the responsible VC backend of the given @var{file}. For example, if @file{emacs.c} is a file tracked by git, @code{(vc-responsible-backend "emacs.c")} returns @samp{Git}. Note that if @var{file} is a symbolic link, @code{vc-responsible-backend} will not resolve it---the backend of the symbolic link file itself is reported. Instead, to get the backend VC of the file to which @var{file} refers, wrap @var{file} with a symbolic link resolving function such as @code{file-chase-links}: @smallexample (vc-responsible-backend (file-chase-links "emacs.c")) @end smallexample @end defun --------------------- vc-responsible-backend defun ENDS--------------------- > Last, but not least: documentation changes need ChangeLog-style commit > log messages as well (just use "C-x 4 a" to get a preformatted > skeleton from which you could start). Fixed in the new patch. The new version now also mentions `vc-responsible-backend' in a different way in maintaining.texi. Feel free to review again. Thanks! [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1.2: vc-doc-1.patch --] [-- Type: text/x-diff, Size: 2069 bytes --] diff --git a/doc/emacs/ChangeLog.1 b/doc/emacs/ChangeLog.1 index 3f746ebd763f..c5d150af8124 100644 --- a/doc/emacs/ChangeLog.1 +++ b/doc/emacs/ChangeLog.1 @@ -1,3 +1,8 @@ +2016-10-30 Hong Xu <hong@topbug.net> + + * maintaining.texi (Version Control Systems): Mention + `vc-responsible-backend' when explaining VC back ends. + 2015-03-29 Dani Moncayo <dmoncayo@gmail.com> * files.texi (Diff Mode): Doc fix. diff --git a/doc/emacs/maintaining.texi b/doc/emacs/maintaining.texi index aca29910b7d3..884d40be5634 100644 --- a/doc/emacs/maintaining.texi +++ b/doc/emacs/maintaining.texi @@ -223,7 +223,7 @@ Version Control Systems @cindex SRC @cindex src @item -SRC (src) is RCS, reloaded - a specialized version-control system +SRC (src) is RCS, reloaded---a specialized version-control system designed for single-file projects worked on by only one person. It allows multiple files with independent version-control histories to exist in one directory, and is thus particularly well suited for @@ -233,6 +233,10 @@ Version Control Systems supports almost all SRC operations. @end itemize +@findex vc-responsible-backend +To determine which back end is in charge of a file, the function +@code{vc-responsible-backend} can be used. + @node VCS Concepts @subsubsection Concepts of Version Control diff --git a/lisp/vc/vc.el b/lisp/vc/vc.el index ac020d095397..2ddf4e19e1f7 100644 --- a/lisp/vc/vc.el +++ b/lisp/vc/vc.el @@ -959,7 +959,11 @@ vc-responsible-backend If FILE is already registered, return the backend of FILE. If FILE is not registered, then the first backend in `vc-handled-backends' that declares itself -responsible for FILE is returned." +responsible for FILE is returned. + +Note that if FILE is a symbolic link, it will not be resolved -- +the responsible backend system for the symbolic link itself will +be reported." (or (and (not (file-directory-p file)) (vc-backend file)) (catch 'found ;; First try: find a responsible backend. If this is for registration, [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 818 bytes --] ^ permalink raw reply related [flat|nested] 31+ messages in thread
* bug#23436: [PATCH] Attemp to use the true name of a file to determine responsible vc if the genuine name does not work. 2016-10-30 22:50 ` Hong Xu @ 2016-10-31 15:43 ` Eli Zaretskii 2016-10-31 19:38 ` Hong Xu 0 siblings, 1 reply; 31+ messages in thread From: Eli Zaretskii @ 2016-10-31 15:43 UTC (permalink / raw) To: Hong Xu; +Cc: dgutov, 23436 > From: Hong Xu <hong@topbug.net> > Cc: dgutov@yandex.ru, 23436@debbugs.gnu.org > Date: Sun, 30 Oct 2016 15:50:56 -0700 > > > This should go to the ELisp manual, not the Emacs User manual. > > > > I don't know how to resolve this issue: there seems no proper place to > insert the defun section. The node "Truenames" sounds like a good place. This version of the patch is fine with me, thanks. ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#23436: [PATCH] Attemp to use the true name of a file to determine responsible vc if the genuine name does not work. 2016-10-31 15:43 ` Eli Zaretskii @ 2016-10-31 19:38 ` Hong Xu 2016-11-01 18:47 ` Eli Zaretskii 0 siblings, 1 reply; 31+ messages in thread From: Hong Xu @ 2016-10-31 19:38 UTC (permalink / raw) To: Eli Zaretskii; +Cc: dgutov, 23436 [-- Attachment #1.1: Type: text/plain, Size: 202 bytes --] On 2016-10-31 Mon 08:43 GMT-0700, Eli Zaretskii <eliz@gnu.org> wrote: > > The node "Truenames" sounds like a good place. > Added in the new patch now (along with the change of the previous version). [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1.2: vc-doc-2.patch --] [-- Type: text/x-diff, Size: 3519 bytes --] diff --git a/doc/emacs/ChangeLog.1 b/doc/emacs/ChangeLog.1 index 3f746ebd763f..c5d150af8124 100644 --- a/doc/emacs/ChangeLog.1 +++ b/doc/emacs/ChangeLog.1 @@ -1,3 +1,8 @@ +2016-10-30 Hong Xu <hong@topbug.net> + + * maintaining.texi (Version Control Systems): Mention + `vc-responsible-backend' when explaining VC back ends. + 2015-03-29 Dani Moncayo <dmoncayo@gmail.com> * files.texi (Diff Mode): Doc fix. diff --git a/doc/emacs/maintaining.texi b/doc/emacs/maintaining.texi index aca29910b7d3..884d40be5634 100644 --- a/doc/emacs/maintaining.texi +++ b/doc/emacs/maintaining.texi @@ -223,7 +223,7 @@ Version Control Systems @cindex SRC @cindex src @item -SRC (src) is RCS, reloaded - a specialized version-control system +SRC (src) is RCS, reloaded---a specialized version-control system designed for single-file projects worked on by only one person. It allows multiple files with independent version-control histories to exist in one directory, and is thus particularly well suited for @@ -233,6 +233,10 @@ Version Control Systems supports almost all SRC operations. @end itemize +@findex vc-responsible-backend +To determine which back end is in charge of a file, the function +@code{vc-responsible-backend} can be used. + @node VCS Concepts @subsubsection Concepts of Version Control diff --git a/doc/lispref/ChangeLog.1 b/doc/lispref/ChangeLog.1 index 610e7541e7de..2d00ac7e7d32 100644 --- a/doc/lispref/ChangeLog.1 +++ b/doc/lispref/ChangeLog.1 @@ -1,3 +1,8 @@ +2016-10-31 Hong Xu <hong@topbug.net> + + * files.texi (Truenames): Add documentation for + `vc-responsible-backend'. + 2015-03-29 Glenn Morris <rgm@gnu.org> * objects.texi (Equality Predicates): Fix typo in example. diff --git a/doc/lispref/files.texi b/doc/lispref/files.texi index 6b7ee19d5f39..0be8b83831b2 100644 --- a/doc/lispref/files.texi +++ b/doc/lispref/files.texi @@ -1138,6 +1138,21 @@ Truenames name an existing directory, the return value is @code{nil}. @end defun +@defun vc-responsible-backend file +This function determines the responsible VC backend of the given +@var{file}. For example, if @file{emacs.c} is a file tracked by git, +@code{(vc-responsible-backend "emacs.c")} returns @samp{Git}. Note +that if @var{file} is a symbolic link, @code{vc-responsible-backend} +will not resolve it---the backend of the symbolic link file itself is +reported. Instead, to get the backend VC of the file to which +@var{file} refers, wrap @var{file} with a symbolic link resolving +function such as @code{file-chase-links}: + +@smallexample +(vc-responsible-backend (file-chase-links "emacs.c")) +@end smallexample +@end defun + @node File Attributes @subsection File Attributes @cindex file attributes diff --git a/lisp/vc/vc.el b/lisp/vc/vc.el index ac020d095397..2ddf4e19e1f7 100644 --- a/lisp/vc/vc.el +++ b/lisp/vc/vc.el @@ -959,7 +959,11 @@ vc-responsible-backend If FILE is already registered, return the backend of FILE. If FILE is not registered, then the first backend in `vc-handled-backends' that declares itself -responsible for FILE is returned." +responsible for FILE is returned. + +Note that if FILE is a symbolic link, it will not be resolved -- +the responsible backend system for the symbolic link itself will +be reported." (or (and (not (file-directory-p file)) (vc-backend file)) (catch 'found ;; First try: find a responsible backend. If this is for registration, [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 818 bytes --] ^ permalink raw reply related [flat|nested] 31+ messages in thread
* bug#23436: [PATCH] Attemp to use the true name of a file to determine responsible vc if the genuine name does not work. 2016-10-31 19:38 ` Hong Xu @ 2016-11-01 18:47 ` Eli Zaretskii 2016-11-04 7:46 ` Hong Xu 0 siblings, 1 reply; 31+ messages in thread From: Eli Zaretskii @ 2016-11-01 18:47 UTC (permalink / raw) To: Hong Xu; +Cc: dgutov, 23436 > From: Hong Xu <hong@topbug.net> > Cc: dgutov@yandex.ru, 23436@debbugs.gnu.org > Date: Mon, 31 Oct 2016 12:38:42 -0700 > > On 2016-10-31 Mon 08:43 GMT-0700, Eli Zaretskii <eliz@gnu.org> wrote: > > > > The node "Truenames" sounds like a good place. > > Added in the new patch now (along with the change of the previous version). LGTM, thanks. ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#23436: [PATCH] Attemp to use the true name of a file to determine responsible vc if the genuine name does not work. 2016-11-01 18:47 ` Eli Zaretskii @ 2016-11-04 7:46 ` Hong Xu 2016-11-04 10:08 ` Eli Zaretskii 0 siblings, 1 reply; 31+ messages in thread From: Hong Xu @ 2016-11-04 7:46 UTC (permalink / raw) To: Eli Zaretskii; +Cc: dgutov, 23436 [-- Attachment #1: Type: text/plain, Size: 500 bytes --] On 2016-11-01 Tue 11:47 GMT-0700, Eli Zaretskii <eliz@gnu.org> wrote: >> From: Hong Xu <hong@topbug.net> >> Cc: dgutov@yandex.ru, 23436@debbugs.gnu.org >> Date: Mon, 31 Oct 2016 12:38:42 -0700 >> >> On 2016-10-31 Mon 08:43 GMT-0700, Eli Zaretskii <eliz@gnu.org> wrote: >> > >> > The node "Truenames" sounds like a good place. >> >> Added in the new patch now (along with the change of the previous version). > > LGTM, thanks. Can we apply the patch if it is good enough? Thanks. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 818 bytes --] ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#23436: [PATCH] Attemp to use the true name of a file to determine responsible vc if the genuine name does not work. 2016-11-04 7:46 ` Hong Xu @ 2016-11-04 10:08 ` Eli Zaretskii 0 siblings, 0 replies; 31+ messages in thread From: Eli Zaretskii @ 2016-11-04 10:08 UTC (permalink / raw) To: Hong Xu; +Cc: 23436-done, dgutov > From: Hong Xu <hong@topbug.net> > Cc: dgutov@yandex.ru, 23436@debbugs.gnu.org > Date: Fri, 04 Nov 2016 00:46:05 -0700 > > On 2016-11-01 Tue 11:47 GMT-0700, Eli Zaretskii <eliz@gnu.org> wrote: > > >> From: Hong Xu <hong@topbug.net> > >> Cc: dgutov@yandex.ru, 23436@debbugs.gnu.org > >> Date: Mon, 31 Oct 2016 12:38:42 -0700 > >> > >> On 2016-10-31 Mon 08:43 GMT-0700, Eli Zaretskii <eliz@gnu.org> wrote: > >> > > >> > The node "Truenames" sounds like a good place. > >> > >> Added in the new patch now (along with the change of the previous version). > > > > LGTM, thanks. > > Can we apply the patch if it is good enough? Thanks. Pushed now. Please note that I generally wait for a week or so since the last comment before pushing changes, to let people enough time to comment or object. ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#23436: [PATCH] Attemp to use the true name of a file to determine responsible vc if the genuine name does not work. 2016-10-30 0:42 ` Hong Xu 2016-10-30 16:21 ` Eli Zaretskii @ 2016-10-31 11:34 ` Dmitry Gutov 2016-10-31 19:24 ` Hong Xu 1 sibling, 1 reply; 31+ messages in thread From: Dmitry Gutov @ 2016-10-31 11:34 UTC (permalink / raw) To: Hong Xu; +Cc: 23436 On 30.10.2016 03:42, Hong Xu wrote: > OK, I think I have screwed it up. vc-responsible-backend looks like a function > mainly provided for elisp programming purpose, which people can make use > in their own customization. Thus, none of these functions should be > used. Instead, file-truename or file-chase-links should be used. Please clarify: will you be satisfied with a documentation-only change? ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#23436: [PATCH] Attemp to use the true name of a file to determine responsible vc if the genuine name does not work. 2016-10-31 11:34 ` Dmitry Gutov @ 2016-10-31 19:24 ` Hong Xu 0 siblings, 0 replies; 31+ messages in thread From: Hong Xu @ 2016-10-31 19:24 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 23436 [-- Attachment #1: Type: text/plain, Size: 524 bytes --] On 2016-10-31 Mon 04:34 GMT-0700, Dmitry Gutov <dgutov@yandex.ru> wrote: > On 30.10.2016 03:42, Hong Xu wrote: > >> OK, I think I have screwed it up. vc-responsible-backend looks like a function >> mainly provided for elisp programming purpose, which people can make use >> in their own customization. Thus, none of these functions should be >> used. Instead, file-truename or file-chase-links should be used. > > Please clarify: will you be satisfied with a documentation-only change? Yes, IMO it should be good enough. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 818 bytes --] ^ permalink raw reply [flat|nested] 31+ messages in thread
end of thread, other threads:[~2016-11-04 10:08 UTC | newest] Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-05-03 21:32 bug#23436: [PATCH] Use the true name of a file to determine responsible vc Hong Xu 2016-10-19 19:19 ` Hong Xu 2016-10-19 19:33 ` bug#23436: [PATCH] Attemp to use the true name of a file to determine responsible vc if the genuine name does not work Hong Xu 2016-10-19 23:37 ` Dmitry Gutov 2016-10-19 23:49 ` Hong Xu 2016-10-19 23:58 ` Dmitry Gutov 2016-10-20 0:16 ` Hong Xu 2016-10-20 6:58 ` Eli Zaretskii 2016-10-20 7:21 ` Hong Xu 2016-10-20 8:23 ` Eli Zaretskii 2016-10-20 8:50 ` Dmitry Gutov 2016-10-20 9:46 ` Andreas Schwab 2016-10-20 10:02 ` Eli Zaretskii 2016-10-20 10:58 ` Eli Zaretskii 2016-10-20 9:47 ` Dmitry Gutov 2016-10-20 16:39 ` Hong Xu 2016-10-20 22:34 ` Dmitry Gutov 2016-10-20 23:04 ` Hong Xu 2016-10-24 23:41 ` Dmitry Gutov 2016-10-25 19:05 ` Hong Xu 2016-10-25 23:12 ` Dmitry Gutov 2016-10-30 0:42 ` Hong Xu 2016-10-30 16:21 ` Eli Zaretskii 2016-10-30 22:50 ` Hong Xu 2016-10-31 15:43 ` Eli Zaretskii 2016-10-31 19:38 ` Hong Xu 2016-11-01 18:47 ` Eli Zaretskii 2016-11-04 7:46 ` Hong Xu 2016-11-04 10:08 ` Eli Zaretskii 2016-10-31 11:34 ` Dmitry Gutov 2016-10-31 19:24 ` Hong Xu
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).