From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Wolfgang Scherer Newsgroups: gmane.emacs.bugs Subject: bug#37189: 25.4.1: vc-hg-ignore implementation is missing Date: Thu, 13 Feb 2020 02:18:00 +0100 Message-ID: References: <1ba53ae2-42a4-3ab3-d4f2-2ceae565d198@gmx.de> <95da41e8-7a55-a15c-cfa7-d70366f9ee6b@gmx.de> <412195c1-e196-12af-933b-0312f5075847@yandex.ru> <57825d73-27a4-d5f5-8198-a172796a558a@gmx.de> <1ebc6077-9175-65ba-4996-282bb2c8eca5@yandex.ru> <6145d6f6-37a8-7166-731b-57669086b145@gmx.de> <838slmk90j.fsf@gnu.org> <83h806gp2w.fsf@gnu.org> <8336bmg1o9.fsf@gnu.org> <2354821b-5c1e-f9e3-3a64-4ff978ded33b@gmx.de> <83sgjkdev5.fsf@gnu.org> <3fb73dbc-bf31-233b-4afc-2147c4ffd5b7@gmx.de> <5622487d-a21f-49cf-5420-21f87415af4f@gmx.de> <83wo8ubfbo.fsf@gnu.org> <83zhdpqbas.fsf@gnu.org> <2c8419ae-723d-c7ae-a60e-59d1b1cbc2c1@gmx.de> <83o8u3r6wg.fsf@gnu.org> <6f3ba261-e1f9-cf19-cc22-ec8c24cf3298@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="125844"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 Cc: 37189@debbugs.gnu.org, dgutov@yandex.ru To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Feb 13 02:19:34 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1j23AE-000We1-9Y for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 13 Feb 2020 02:19:34 +0100 Original-Received: from localhost ([::1]:45806 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j23AC-000451-NL for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 12 Feb 2020 20:19:32 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44925) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j239j-00044o-NZ for bug-gnu-emacs@gnu.org; Wed, 12 Feb 2020 20:19:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j239i-00051J-Cq for bug-gnu-emacs@gnu.org; Wed, 12 Feb 2020 20:19:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:53268) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j239i-000513-8w for bug-gnu-emacs@gnu.org; Wed, 12 Feb 2020 20:19:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1j239i-0002Ob-59 for bug-gnu-emacs@gnu.org; Wed, 12 Feb 2020 20:19:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Wolfgang Scherer Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 13 Feb 2020 01:19:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37189 X-GNU-PR-Package: emacs Original-Received: via spool by 37189-submit@debbugs.gnu.org id=B37189.15815566919137 (code B ref 37189); Thu, 13 Feb 2020 01:19:02 +0000 Original-Received: (at 37189) by debbugs.gnu.org; 13 Feb 2020 01:18:11 +0000 Original-Received: from localhost ([127.0.0.1]:59241 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j238t-0002NJ-2g for submit@debbugs.gnu.org; Wed, 12 Feb 2020 20:18:11 -0500 Original-Received: from mout.gmx.net ([212.227.15.15]:35765) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j238q-0002N2-HH for 37189@debbugs.gnu.org; Wed, 12 Feb 2020 20:18:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1581556682; bh=VyFwktKnk1cIA3jQHB0lLUrol/4uhKJywEcUtMZKjMU=; h=X-UI-Sender-Class:Subject:From:To:Cc:References:Date:In-Reply-To; b=NhMejNosDagvicAXP2WnoumyXiBcdMS29ekQwC6EZEHCGFqswDv9Kt8VMswrROpEF 2VhqDb969pUVyhM1JUsWhMpidv1HQuMmec41Z/2CiyrnRJm2WwWyso+xGDzzhhAzHu kH1KTIe2be7u2/23Dg4oUcLonnn6/FjumilJGYP8= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from sheckley.simul.de ([87.160.210.52]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1Mk0Ne-1jm5Cs03Eu-00kMJQ; Thu, 13 Feb 2020 02:18:02 +0100 Original-Received: from [127.0.0.1] (sheckley.simul.de [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by sheckley.simul.de (Postfix) with ESMTPSA id 5604719431D7; Thu, 13 Feb 2020 02:18:00 +0100 (CET) Openpgp: preference=signencrypt Autocrypt: addr=Wolfgang.Scherer@gmx.de; prefer-encrypt=mutual; keydata= xsDiBEb46IgRBACMHOAb1KNo1Ylk+ebri+4R+bG4tyKlqBlrpv8D9/ZwRdXSGt+0DyCHoaAd 7KW7noHapLe87DunABOjKG4nqTGv+dRiWuUBlp3I4aYRFDVa3Da+XnIYkMHKqhK59VEHQCdp Km42nuLS7TS+n99at9YwzTG6VBdOlBKTlRFngOjVLwCg1RGXJ6X3EjS1FKCQeXziURVpWlkD /2zY6Ayhxi62TS84VjikXrrmjXykAAaAmMVEyKKYb9L5pGlqiZz9g/K9xw1EUoZTYuaufquD v4rAGR58K/3V4CYfJLEeshMWiaXHvMmlxMznlG16/um4MvmR8B3r+cx0nOPK1JBdD2qrkNnF Mw8FB+zouLFB4Gt2IUC5IlOmZ8OQA/4qdU53CItzWsCr9Nux4L0qUlRweSmCnV8xGQ2wP5XI MawIQxxREvSrsYDG8cNnYETMg4iQFfIktwAoxCJvuFAwIB6ZxHGF4FcEZm64CXc2u7CmFLqt rVhXhIfMz9oEYC+HhGczGamn9ofbGTFd2hJEtPcQgWNR4f7+aKknmi2+OM0fV29sZmdhbmcg U2NoZXJlciA8d3NAc3ctYW10LndzPsJhBBMRAgAhBQJYmz3YAhsjBQsJCAcCBhUICQoLAgQW AgMBAh4BAheAAAoJEIUCr3Gr112VZZoAoLTBSTp1qGuNhLdXY04iaWCMYmHCAJ4kHPtQ6nTw kEq9qCHgVgXDaY7wjs7ATQRG+OiIEAQAhi0wjcxvA4tychg2NQuwBIf9LX/46l+74+QbewCn a4a+mw/9s5KY In-Reply-To: Content-Language: de-DE X-Provags-ID: V03:K1:UvIgDMl6xJuFH4rjAKEywQnhjaiULSMKV+/A+jWL46XQdVELhdD z5dRSYpFdW3eLDflyK7FImwhTtdSZNAsvVXFptDJA10Vbg9hoZLj1yzGAsd0BdKTKAHeemI jN1rv/pQMXijcPear5IVitno6HUNgj+wYh8RJ2gWu8/d2Z4go9mnqkLgKlq5E/jFFcfE79/ EfmHotkHd90jR0NQE4Vkg== X-UI-Out-Filterresults: notjunk:1;V03:K0:5CUOzn5Ysu8=:2xsw0LMt0f10xIwXruLA9o 9rj01lt2h8RY9JBGyrLUrXfapjsRrQS7TqDPYzWmZ/QIXvuIN5kIqs0d4cyX14EJ1YbI+7lc+ 9LZNTv3eXYay/8FC6HvbpR8MXkO3oX3SkwvQ87cGbZTJ9FEQLore5uIYMjFQ/HqMOzUnFdLBX L39Ev6mdnkQ4SswHp7P2MecDi7RQVKHx/vussQXJipMhDNONAH2Oh1eZPAUoM95S8aXQjUWIm 9uwgrgkuaJ5alCOrBmWSuZoxQTYr24sZgFawP73UeK9QX5QJ71VcEjwkc1fcBbrZZU5BlCS0i cjxTtslMGEQA0F7AGYPpr4JDsL2tpBJKZPkwWmKYVyOUXq/Ued3XfXYPQIYN8yixg2E4VfhfG 4oiMLwgUSEjeSyRffvy26ngcKnMVlcVxmaUxbzbJmnUAjOkSMeRI8p9hGrONvzLXe6qGbO7R1 XrvckRpxm84gQ07OHBnSJPyY6Sp0gfGF+Qrevgl94WWgJheaqZ49JZXDGT2XC16vUICAfbe65 Z7N9FxHlMeUdoRb8doqd0hwchR+bteMycV+wwjECTg4gcZoyw0BfJqPUSTiTrK7NWQGO4rD9K R9JIbSI6tjJkiBXJfTHA5XgHuceC2RLBJgWIN6dhs95UnrXYjnNi9vD/ksyAgZfi0rErGrNJl tTKEdzfqGe9SD0EtnF9pjjL66oU5CKRoddIMij+kjCkpfHlo6aeoePDpzplKVrG3Vwx6AK+Yv lvik5XLI5S1sHdfClP5DhUs1vhtBY2ri8q1W2ucop+C1EhgpRbOOHmUqYe/pcQttRd7V/Iyd 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: 209.51.188.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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:175990 Archived-At: Hi Eli, you must be using an Emacs < 27, if you get basenames in root/.gitignore, = because that behavior changed with #37217: > Only the basename of FILE is written to the ignore file. This is > wrong for all filenames relative to project root with one ore > more parent directories. > > The remove option is also implemented incorrectly. I have totally forgotten, that I never really considered the "pattern" use case you are so fond of, because the "file path" (vc-dir-ignore) use case was so much more obvious to me.=C2=A0 Since I have fixed so much of vc's shortcomings already, I have not really thought of the original behavior until you asked me to show, why vc-ignore had always been broken. So, I just tried this in a Mercurial repository (it is fine to use Git, as long as you can pretend that regular expressions are valid wildcards): 1. Invoke vc-ignore `C-x v G` 2. Enter the correct regular expression for Mercurial (it is a =C2=A0=C2=A0 wildcard for the VC according to your reasoning, is it not?): =C2=A0=C2=A0 ^/some[/]sub 3. Check your .hgignore file and verify, that it only contains: =C2=A0=C2=A0 ]sub How is that behavior correct?=C2=A0 There should have been no change, because the user is supposed to do everything themselves, right? So how come, the correct documentation for vc-ignore before Emacs 27 is basically: =C2=A0=C2=A0=C2=A0 (defun (vc-ignore FILE &optional DIRECTORY REMOVE) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "... =C2=A0=C2=A0=C2=A0 You will be prompted for an absolute file path, but don= 't think =C2=A0=C2=A0=C2=A0 that it has any significance, because for Bzr, Git, Hg,= Mnt: =C2=A0=C2=A0=C2=A0 If you enter anything that ends with a slash, the strin= g "./" is =C2=A0=C2=A0=C2=A0 written into the nearest ignore file. =C2=A0=C2=A0=C2=A0 Otherwise, everything up to and including the last slas= h is thrown =C2=A0=C2=A0=C2=A0 away and the rest is written into the nearest ignore fi= le. =C2=A0=C2=A0=C2=A0 For CVS, whatever is entered is used as a filename to d= etermine =C2=A0=C2=A0=C2=A0 the directory of the ignore file. What ever was entered= is then =C2=A0=C2=A0=C2=A0 written entirely into that ignore file without modifica= tion, which =C2=A0=C2=A0=C2=A0 makes no sense. =C2=A0=C2=A0=C2=A0 For SVN, other strange things happen." Applying `file-name-nondirectory` to an escaped pattern *never makes any sense at all*, so why does it happen? The simplest explanation is, that there is no "pattern" use case at all. There is really only one use case, which is to ignore files by pressing `G` in vc-dir-mode. The additional shortcut `C-x v G` for vc-ignore is just there to make things symmetrical with other VC commands like `i` and `C-x v i` and so forth. That is also the reason why vc-ignore prompts for an absolute file name. Because it is the exact same input it gets from vc-dir-ignore. Case closed. vc-ignore does not have a pattern mode. It was always broken entirely. Period. So the implementation you are talking about has never existed, you are just trying to somehow justify the broken behavior by making stuff up and insisting that the behavior is intentional. Let me ensure you, that it is not. And if something is so utterly broken like the original vc ignore feature, we are not talking about an API change but about a proper refactoring to get it working at all. Any solution is better than no solution. I actually like the idea of a "pattern" input, so I am not sad about the lost time. But I will now quit this absurd discussion of non-existing algorithms and just keep working with my correct implementation of the vc ignore feature. Should you get your facts straight, we can talk further. Otherwise, I have invested enough.time now. Am 13.02.20 um 00:20 schrieb Wolfgang Scherer: >>>> The old behavior of vc-ignore was not broken for interactive >>>> invocations. It was broken (in rare cases) for invocations from >>>> vc-dir-ignore, and that can IMO be fixed without affecting user-facin= g >>>> behavior. So I see no backward-incompatible changes here. >>> Sorry, not *rare* but **all** cases! The invocation from vc-dir-ignore >>> placed an **absolute file path** into the ignore file. >> That's not what I see, at least not with Git as the backend. I see >> only the basename of the file being added to the ignore file. > Right, and that is incorrect for all cases, because it is > > 1. not anchored, i.e.it also matches files with the same name in > subdirectories, > 2. if the basename comes from a file in a subdirectory, it also > matches files with the same name in the root directory. > > These reasons also apply to Bzr,Hg, Mtn, since the same functions are > used. BTW, you are seeing these incorrect filenames so flawlessly, > because I fixed the underlying functions in #37185 extensively. > > Originally, SVN at least got it right for files in the root directory, > but none of the ignore specs for files in a subdirectory ever matched > anything, which is probably better than matching the wrong thing.. > >> Can you >> show a use case where an absolute file name is written into the ignore >> file by vc-dir-ignore? > Yes, CVS is still broken in that manner, because the reviewer of > #37215 thinks, that FILE is always a basename only. > > And there we are, *all* backend implementations fail utterly for > vc-dir-ignore. Not just *rare*, but *almost all* cases (except root > directory of SVN repo). >