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