GNU bug report logs - #23436
[PATCH] Use the true name of a file to determine responsible vc.

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 23436 in the body.
You can then email your comments to 23436 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Hong Xu <hong <at> topbug.net>
To: bug-gnu-emacs <at> gnu.org
Cc: Hong Xu <hong <at> topbug.net>
Subject: [PATCH] Use the true name of a file to determine responsible vc.
Date: Tue,  3 May 2016 14:32:25 -0700

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

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Hong Xu <hong <at> topbug.net>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: [PATCH] Use the true name of a file to determine responsible vc.
Date: Wed, 19 Oct 2016 12:19:51 -0700

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

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

[vc.patch (text/x-patch, attachment)]

[signature.asc (application/pgp-signature, attachment)]

Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Hong Xu <hong <at> topbug.net>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: [PATCH] Attemp to use the true name of a file to determine
 responsible vc if the genuine name does not work.
Date: Wed, 19 Oct 2016 12:33:58 -0700

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

Another updated version...

[vc.patch (text/x-patch, attachment)]

[signature.asc (application/pgp-signature, attachment)]

Message #14 received at 23436 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Hong Xu <hong <at> topbug.net>, 23436 <at> debbugs.gnu.org
Subject: Re: bug#23436: [PATCH] Attemp to use the true name of a file to
 determine responsible vc if the genuine name does not work.
Date: Thu, 20 Oct 2016 02:37:14 +0300

On 19.10.2016 22:33, Hong Xu wrote:
> +        (dolist (file-path (list file (file-truename file)))

Why not just use the true name?

Message #17 received at 23436 <at> debbugs.gnu.org (full text, mbox):

From: Hong Xu <hong <at> topbug.net>
To: Dmitry Gutov <dgutov <at> yandex.ru>, 23436 <at> debbugs.gnu.org
Subject: Re: bug#23436: [PATCH] Attemp to use the true name of a file to
 determine responsible vc if the genuine name does not work.
Date: Wed, 19 Oct 2016 16:49:15 -0700

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

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.

[signature.asc (application/pgp-signature, attachment)]

Message #20 received at 23436 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Hong Xu <hong <at> topbug.net>, 23436 <at> debbugs.gnu.org
Subject: Re: bug#23436: [PATCH] Attemp to use the true name of a file to
 determine responsible vc if the genuine name does not work.
Date: Thu, 20 Oct 2016 02:58:14 +0300

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.

Message #23 received at 23436 <at> debbugs.gnu.org (full text, mbox):

From: Hong Xu <hong <at> topbug.net>
To: Dmitry Gutov <dgutov <at> yandex.ru>, 23436 <at> debbugs.gnu.org
Subject: Re: bug#23436: [PATCH] Attemp to use the true name of a file to
 determine responsible vc if the genuine name does not work.
Date: Wed, 19 Oct 2016 17:16:58 -0700

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

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.

[signature.asc (application/pgp-signature, attachment)]

Message #26 received at 23436 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Hong Xu <hong <at> topbug.net>
Cc: 23436 <at> debbugs.gnu.org, dgutov <at> yandex.ru
Subject: Re: bug#23436: [PATCH] Attemp to use the true name of a file to
 determine responsible vc if the genuine name does not work.
Date: Thu, 20 Oct 2016 09:58:13 +0300

> From: Hong Xu <hong <at> 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?

Message #29 received at 23436 <at> debbugs.gnu.org (full text, mbox):

From: Hong Xu <hong <at> topbug.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 23436 <at> debbugs.gnu.org, dgutov <at> yandex.ru
Subject: Re: bug#23436: [PATCH] Attemp to use the true name of a file to
 determine responsible vc if the genuine name does not work.
Date: Thu, 20 Oct 2016 00:21:31 -0700

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

On 10/19/2016 11:58 PM, Eli Zaretskii wrote:
>> From: Hong Xu <hong <at> 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.

[signature.asc (application/pgp-signature, attachment)]

Message #32 received at 23436 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Hong Xu <hong <at> topbug.net>
Cc: 23436 <at> debbugs.gnu.org, dgutov <at> yandex.ru
Subject: Re: bug#23436: [PATCH] Attemp to use the true name of a file to
 determine responsible vc if the genuine name does not work.
Date: Thu, 20 Oct 2016 11:23:36 +0300

> Cc: dgutov <at> yandex.ru, 23436 <at> debbugs.gnu.org
> From: Hong Xu <hong <at> 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 <at> 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?

Message #35 received at 23436 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>, Hong Xu <hong <at> topbug.net>
Cc: 23436 <at> debbugs.gnu.org
Subject: Re: bug#23436: [PATCH] Attemp to use the true name of a file to
 determine responsible vc if the genuine name does not work.
Date: Thu, 20 Oct 2016 11:50:07 +0300

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.

Message #38 received at 23436 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> suse.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: dgutov <at> yandex.ru, 23436 <at> debbugs.gnu.org, Hong Xu <hong <at> topbug.net>
Subject: Re: bug#23436: [PATCH] Attemp to use the true name of a file to
 determine responsible vc if the genuine name does not work.
Date: Thu, 20 Oct 2016 11:46:50 +0200

On Okt 20 2016, Eli Zaretskii <eliz <at> 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 <at> suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Message #41 received at 23436 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Hong Xu <hong <at> topbug.net>, 23436 <at> debbugs.gnu.org
Subject: Re: bug#23436: [PATCH] Attemp to use the true name of a file to
 determine responsible vc if the genuine name does not work.
Date: Thu, 20 Oct 2016 12:47:03 +0300

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.

Message #44 received at 23436 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andreas Schwab <schwab <at> suse.de>
Cc: dgutov <at> yandex.ru, 23436 <at> debbugs.gnu.org, hong <at> topbug.net
Subject: Re: bug#23436: [PATCH] Attemp to use the true name of a file to
 determine responsible vc if the genuine name does not work.
Date: Thu, 20 Oct 2016 13:02:51 +0300

> From: Andreas Schwab <schwab <at> suse.de>
> Cc: Hong Xu <hong <at> topbug.net>,  dgutov <at> yandex.ru,  23436 <at> debbugs.gnu.org
> Date: Thu, 20 Oct 2016 11:46:50 +0200
> 
> On Okt 20 2016, Eli Zaretskii <eliz <at> 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?

Message #47 received at 23436 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: schwab <at> suse.de, hong <at> topbug.net
Cc: dgutov <at> yandex.ru, 23436 <at> debbugs.gnu.org
Subject: Re: bug#23436: [PATCH] Attemp to use the true name of a file to
 determine responsible vc if the genuine name does not work.
Date: Thu, 20 Oct 2016 13:58:55 +0300

> Date: Thu, 20 Oct 2016 13:02:51 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: hong <at> topbug.net, 23436 <at> debbugs.gnu.org, dgutov <at> 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.

Message #50 received at 23436 <at> debbugs.gnu.org (full text, mbox):

From: Hong Xu <hong <at> topbug.net>
To: Dmitry Gutov <dgutov <at> yandex.ru>, 23436 <at> debbugs.gnu.org
Subject: Re: bug#23436: [PATCH] Attemp to use the true name of a file to
 determine responsible vc if the genuine name does not work.
Date: Thu, 20 Oct 2016 09:39:45 -0700

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

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.

[signature.asc (application/pgp-signature, attachment)]

Message #53 received at 23436 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Hong Xu <hong <at> topbug.net>, 23436 <at> debbugs.gnu.org
Subject: Re: bug#23436: [PATCH] Attemp to use the true name of a file to
 determine responsible vc if the genuine name does not work.
Date: Fri, 21 Oct 2016 01:34:24 +0300

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?

Message #56 received at 23436 <at> debbugs.gnu.org (full text, mbox):

From: Hong Xu <hong <at> topbug.net>
To: Dmitry Gutov <dgutov <at> yandex.ru>, 23436 <at> debbugs.gnu.org
Subject: Re: bug#23436: [PATCH] Attemp to use the true name of a file to
 determine responsible vc if the genuine name does not work.
Date: Thu, 20 Oct 2016 16:04:02 -0700

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

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.

[signature.asc (application/pgp-signature, attachment)]

Message #59 received at 23436 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Hong Xu <hong <at> topbug.net>, 23436 <at> debbugs.gnu.org
Subject: Re: bug#23436: [PATCH] Attemp to use the true name of a file to
 determine responsible vc if the genuine name does not work.
Date: Tue, 25 Oct 2016 02:41:31 +0300

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?

Message #62 received at 23436 <at> debbugs.gnu.org (full text, mbox):

From: Hong Xu <hong <at> topbug.net>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 23436 <at> debbugs.gnu.org
Subject: Re: bug#23436: [PATCH] Attemp to use the true name of a file to
 determine responsible vc if the genuine name does not work.
Date: Tue, 25 Oct 2016 12:05:49 -0700

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

On Mon, Oct 24 2016, Dmitry Gutov <dgutov <at> 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.

[signature.asc (application/pgp-signature, inline)]

Message #65 received at 23436 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Hong Xu <hong <at> topbug.net>
Cc: 23436 <at> debbugs.gnu.org
Subject: Re: bug#23436: [PATCH] Attemp to use the true name of a file to
 determine responsible vc if the genuine name does not work.
Date: Wed, 26 Oct 2016 02:12:21 +0300

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?

Message #68 received at 23436 <at> debbugs.gnu.org (full text, mbox):

From: Hong Xu <hong <at> topbug.net>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 23436 <at> debbugs.gnu.org
Subject: Re: bug#23436: [PATCH] Attemp to use the true name of a file to
 determine responsible vc if the genuine name does not work.
Date: Sat, 29 Oct 2016 17:42:01 -0700

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

On 2016-10-25 Tue 16:12 GMT-0700, Dmitry Gutov <dgutov <at> 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

[vc-doc.patch (text/x-diff, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #71 received at 23436 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Hong Xu <hong <at> topbug.net>
Cc: 23436 <at> debbugs.gnu.org, dgutov <at> yandex.ru
Subject: Re: bug#23436: [PATCH] Attemp to use the true name of a file to
 determine responsible vc if the genuine name does not work.
Date: Sun, 30 Oct 2016 18:21:19 +0200

> From: Hong Xu <hong <at> topbug.net>
> Date: Sat, 29 Oct 2016 17:42:01 -0700
> Cc: 23436 <at> 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).

Message #74 received at 23436 <at> debbugs.gnu.org (full text, mbox):

From: Hong Xu <hong <at> topbug.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 23436 <at> debbugs.gnu.org, dgutov <at> yandex.ru
Subject: Re: bug#23436: [PATCH] Attemp to use the true name of a file to
 determine responsible vc if the genuine name does not work.
Date: Sun, 30 Oct 2016 15:50:56 -0700

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

On 2016-10-30 Sun 09:21 GMT-0700, Eli Zaretskii <eliz <at> 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!

[vc-doc-1.patch (text/x-diff, inline)]

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 <at> topbug.net>
+
+	* maintaining.texi (Version Control Systems): Mention
+	`vc-responsible-backend' when explaining VC back ends.
+
 2015-03-29  Dani Moncayo  <dmoncayo <at> 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,

[signature.asc (application/pgp-signature, inline)]

Message #77 received at 23436 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Hong Xu <hong <at> topbug.net>
Cc: 23436 <at> debbugs.gnu.org
Subject: Re: bug#23436: [PATCH] Attemp to use the true name of a file to
 determine responsible vc if the genuine name does not work.
Date: Mon, 31 Oct 2016 13:34:38 +0200

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?

Message #80 received at 23436 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Hong Xu <hong <at> topbug.net>
Cc: 23436 <at> debbugs.gnu.org, dgutov <at> yandex.ru
Subject: Re: bug#23436: [PATCH] Attemp to use the true name of a file to
 determine responsible vc if the genuine name does not work.
Date: Mon, 31 Oct 2016 17:43:47 +0200

> From: Hong Xu <hong <at> topbug.net>
> Cc: dgutov <at> yandex.ru, 23436 <at> 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.

Message #83 received at 23436 <at> debbugs.gnu.org (full text, mbox):

From: Hong Xu <hong <at> topbug.net>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 23436 <at> debbugs.gnu.org
Subject: Re: bug#23436: [PATCH] Attemp to use the true name of a file to
 determine responsible vc if the genuine name does not work.
Date: Mon, 31 Oct 2016 12:24:23 -0700

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

On 2016-10-31 Mon 04:34 GMT-0700, Dmitry Gutov <dgutov <at> 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.

[signature.asc (application/pgp-signature, inline)]

Message #86 received at 23436 <at> debbugs.gnu.org (full text, mbox):

From: Hong Xu <hong <at> topbug.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 23436 <at> debbugs.gnu.org, dgutov <at> yandex.ru
Subject: Re: bug#23436: [PATCH] Attemp to use the true name of a file to
 determine responsible vc if the genuine name does not work.
Date: Mon, 31 Oct 2016 12:38:42 -0700

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

On 2016-10-31 Mon 08:43 GMT-0700, Eli Zaretskii <eliz <at> 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).

[vc-doc-2.patch (text/x-diff, inline)]

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 <at> topbug.net>
+
+	* maintaining.texi (Version Control Systems): Mention
+	`vc-responsible-backend' when explaining VC back ends.
+
 2015-03-29  Dani Moncayo  <dmoncayo <at> 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 <at> topbug.net>
+
+	* files.texi (Truenames): Add documentation for
+	`vc-responsible-backend'.
+
 2015-03-29  Glenn Morris  <rgm <at> 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,

[signature.asc (application/pgp-signature, inline)]

Message #89 received at 23436 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Hong Xu <hong <at> topbug.net>
Cc: 23436 <at> debbugs.gnu.org, dgutov <at> yandex.ru
Subject: Re: bug#23436: [PATCH] Attemp to use the true name of a file to
 determine responsible vc if the genuine name does not work.
Date: Tue, 01 Nov 2016 20:47:19 +0200

> From: Hong Xu <hong <at> topbug.net>
> Cc: dgutov <at> yandex.ru, 23436 <at> debbugs.gnu.org
> Date: Mon, 31 Oct 2016 12:38:42 -0700
> 
> On 2016-10-31 Mon 08:43 GMT-0700, Eli Zaretskii <eliz <at> 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.

Message #92 received at 23436 <at> debbugs.gnu.org (full text, mbox):

From: Hong Xu <hong <at> topbug.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 23436 <at> debbugs.gnu.org, dgutov <at> yandex.ru
Subject: Re: bug#23436: [PATCH] Attemp to use the true name of a file to
 determine responsible vc if the genuine name does not work.
Date: Fri, 04 Nov 2016 00:46:05 -0700

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

On 2016-11-01 Tue 11:47 GMT-0700, Eli Zaretskii <eliz <at> gnu.org> wrote:

>> From: Hong Xu <hong <at> topbug.net>
>> Cc: dgutov <at> yandex.ru, 23436 <at> debbugs.gnu.org
>> Date: Mon, 31 Oct 2016 12:38:42 -0700
>> 
>> On 2016-10-31 Mon 08:43 GMT-0700, Eli Zaretskii <eliz <at> 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.

[signature.asc (application/pgp-signature, inline)]

Message #97 received at 23436-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Hong Xu <hong <at> topbug.net>
Cc: 23436-done <at> debbugs.gnu.org, dgutov <at> yandex.ru
Subject: Re: bug#23436: [PATCH] Attemp to use the true name of a file to
 determine responsible vc if the genuine name does not work.
Date: Fri, 04 Nov 2016 12:08:59 +0200

> From: Hong Xu <hong <at> topbug.net>
> Cc: dgutov <at> yandex.ru, 23436 <at> debbugs.gnu.org
> Date: Fri, 04 Nov 2016 00:46:05 -0700
> 
> On 2016-11-01 Tue 11:47 GMT-0700, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
> >> From: Hong Xu <hong <at> topbug.net>
> >> Cc: dgutov <at> yandex.ru, 23436 <at> debbugs.gnu.org
> >> Date: Mon, 31 Oct 2016 12:38:42 -0700
> >> 
> >> On 2016-10-31 Mon 08:43 GMT-0700, Eli Zaretskii <eliz <at> 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.

Previous Next

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