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 <hong@topbug.net>]

[-- 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 --]