From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Hong Xu Newsgroups: gmane.emacs.bugs Subject: 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-ID: References: <1462311145-5959-1-git-send-email-hong@topbug.net> <85f11f8a-1799-befd-3e5b-f7d7a6eac660@topbug.net> <072a649f-d11a-7c82-b3ae-32d9a92c8f8b@topbug.net> <5d653522-49bd-8b48-e3d6-0c09d1c65fae@yandex.ru> <837f93v75m.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="HhDoBnDRnPnou1iUQd9BcLT7c1gnox85O" X-Trace: blaine.gmane.org 1476948167 957 195.159.176.226 (20 Oct 2016 07:22:47 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 20 Oct 2016 07:22:47 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.4.0 Cc: dgutov@yandex.ru, 23436@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Oct 20 09:22:43 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bx7gB-0005LR-VZ for geb-bug-gnu-emacs@m.gmane.org; Thu, 20 Oct 2016 09:22:20 +0200 Original-Received: from localhost ([::1]:52888 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bx7gE-0001Lo-6t for geb-bug-gnu-emacs@m.gmane.org; Thu, 20 Oct 2016 03:22:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44607) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bx7fy-0001Kt-Id for bug-gnu-emacs@gnu.org; Thu, 20 Oct 2016 03:22:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bx7fu-0006nv-Iv for bug-gnu-emacs@gnu.org; Thu, 20 Oct 2016 03:22:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:34085) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1bx7fu-0006nZ-G5 for bug-gnu-emacs@gnu.org; Thu, 20 Oct 2016 03:22:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bx7fu-0000l5-8s for bug-gnu-emacs@gnu.org; Thu, 20 Oct 2016 03:22:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Hong Xu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 20 Oct 2016 07:22:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23436 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 23436-submit@debbugs.gnu.org id=B23436.14769481142902 (code B ref 23436); Thu, 20 Oct 2016 07:22:02 +0000 Original-Received: (at 23436) by debbugs.gnu.org; 20 Oct 2016 07:21:54 +0000 Original-Received: from localhost ([127.0.0.1]:40275 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bx7fm-0000kk-3J for submit@debbugs.gnu.org; Thu, 20 Oct 2016 03:21:54 -0400 Original-Received: from sender163-mail.zoho.com ([74.201.84.163]:21445) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bx7fk-0000kb-Uz for 23436@debbugs.gnu.org; Thu, 20 Oct 2016 03:21:53 -0400 Original-Received: from [192.168.88.14] (cpe-104-32-170-214.socal.res.rr.com [104.32.170.214]) by mx.zohomail.com with SMTPS id 147694810431464.95100491800781; Thu, 20 Oct 2016 00:21:44 -0700 (PDT) In-Reply-To: <837f93v75m.fsf@gnu.org> X-Zoho-Virus-Status: 1 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:124711 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HhDoBnDRnPnou1iUQd9BcLT7c1gnox85O Content-Type: multipart/mixed; boundary="unXSKCX4xE0SpR6nVxRJuwuqR7WwCPFvI"; protected-headers="v1" From: Hong Xu To: Eli Zaretskii Cc: dgutov@yandex.ru, 23436@debbugs.gnu.org Message-ID: 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. References: <1462311145-5959-1-git-send-email-hong@topbug.net> <85f11f8a-1799-befd-3e5b-f7d7a6eac660@topbug.net> <072a649f-d11a-7c82-b3ae-32d9a92c8f8b@topbug.net> <5d653522-49bd-8b48-e3d6-0c09d1c65fae@yandex.ru> <837f93v75m.fsf@gnu.org> In-Reply-To: <837f93v75m.fsf@gnu.org> --unXSKCX4xE0SpR6nVxRJuwuqR7WwCPFvI Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/19/2016 11:58 PM, Eli Zaretskii wrote: >> From: Hong Xu >> 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. >=20 > 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? >=20 > 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. --unXSKCX4xE0SpR6nVxRJuwuqR7WwCPFvI-- --HhDoBnDRnPnou1iUQd9BcLT7c1gnox85O Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYCHCHAAoJECZsfTOCL4R4ONAQAJ+tcOrdWhmVE2C54NWjnO8c gjAe2wKcicuLp6iCtpE3LTA+kN4n43N/Vb2tFncVAUKuNbY0hnJ/30yeg4PdAj9q lUlU+zUHrl9TsZ8S4IU2iregAXst11GgucSixgqXBd3fxz6wH9LhpjmFscb9SiIB pBw+DmpHYwZ3Ag2vnf1VsldUt/1QQloalfzTrWlW8z5gJQeezX895BwoG9NkV4Iq WH0tXd19yc24nZvIyWFIZRjhrMAtj6XxS1y9uGLsVbKs7Vl65mK26B+03jcoMKHk VKMynr50GrW1Wut1LJvTr79RPjThoohYGH+wxPceKGHbUA+KjhNpwOOLRXLrjl/w QNk0Fy/SHiFTnqYk6GOMO6nZ2d3hPtxH6FRH8iLtbN8eEeXCi6NxnktYYQEd6oPt zFqdu8OISpEOf4xp9OzWaKdprWqnuOScW92WJCg4rIzHw7GoF7Nluyl9C6YVfF20 tZ9NM8Q8UPwOhZnralIrA1xSjObqYrpKcRBXa9iWFGDRlMoX/YdccA/ndGNWIOyo M83U9lAMuV2Ncyf7YEO5Z8zYrSoQSxO3sCkbwhrjXkWLoz/WYkF45t9rVHdfS01M 3WtYzhPUUxc06HMu1fErugGKM/5nFkB/f8qA/io06FUle2UpgumgNL0Er0ih7a9C 6FViM3vJ5ZP5QDZ5xv7/ =VXtn -----END PGP SIGNATURE----- --HhDoBnDRnPnou1iUQd9BcLT7c1gnox85O--