From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#37189: 25.4.1: vc-hg-ignore implementation is missing Date: Sat, 22 Feb 2020 16:30:35 +0200 Message-ID: <83lfouitis.fsf@gnu.org> References: <1ba53ae2-42a4-3ab3-d4f2-2ceae565d198@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> <83blq2qzqp.fsf@gnu.org> <83ftfdplo8.fsf@gnu.org> <9929b44f-37da-23c8-16cc-c6ca89602149@yandex.ru> <2f84ddff-3275-6eb1-01ae-ff1d28b6e8da@gmx.de> <835zfzjcbv.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="86718"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 37189@debbugs.gnu.org, dgutov@yandex.ru To: Wolfgang Scherer Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Feb 22 15:31:13 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 1j5VoH-000MU6-3A for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 22 Feb 2020 15:31:13 +0100 Original-Received: from localhost ([::1]:43344 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j5VoG-0008Bc-3K for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 22 Feb 2020 09:31:12 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51614) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j5Vo7-0008BH-OX for bug-gnu-emacs@gnu.org; Sat, 22 Feb 2020 09:31:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j5Vo6-0001V0-Gu for bug-gnu-emacs@gnu.org; Sat, 22 Feb 2020 09:31:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:42751) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j5Vo6-0001Uw-De for bug-gnu-emacs@gnu.org; Sat, 22 Feb 2020 09:31:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1j5Vo6-0002sW-As for bug-gnu-emacs@gnu.org; Sat, 22 Feb 2020 09:31:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 22 Feb 2020 14:31: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.158238185411050 (code B ref 37189); Sat, 22 Feb 2020 14:31:02 +0000 Original-Received: (at 37189) by debbugs.gnu.org; 22 Feb 2020 14:30:54 +0000 Original-Received: from localhost ([127.0.0.1]:48724 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j5Vnx-0002s9-JF for submit@debbugs.gnu.org; Sat, 22 Feb 2020 09:30:53 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:36437) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j5Vnu-0002rt-Q7 for 37189@debbugs.gnu.org; Sat, 22 Feb 2020 09:30:51 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:53351) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1j5Vnp-0001Ki-4m; Sat, 22 Feb 2020 09:30:45 -0500 Original-Received: from [176.228.60.248] (port=3221 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1j5Vnn-00030C-Jx; Sat, 22 Feb 2020 09:30:44 -0500 In-reply-to: (message from Wolfgang Scherer on Sat, 22 Feb 2020 14:46:16 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:176398 Archived-At: > Cc: dgutov@yandex.ru, 37189@debbugs.gnu.org > From: Wolfgang Scherer > Date: Sat, 22 Feb 2020 14:46:16 +0100 > > >> Both use cases are important for casual users of a VC. > > I think the issue is not such general, but a more specific one: is the > > use case of ignoring patterns more important than ignoring particular > > files, when we are talking about usage through VC? > How would you measure the importance? By citing experience and anecdotal evidence, I guess. Also, by providing arguments for relative (un)importance of each use case. > >> SRC has ignore files similar to CVS and SVN. > > That's not my reading of the SRC source, which simply does > > > > if line.startswith("#") or not line.strip(): > > continue > > elif line.startswith("!"): > > ignorable -= set(glob.glob(line[1:].strip())) > > else: > > ignorable |= set(glob.glob(line.strip())) > > > > and the Python documentation, which says: > > > > glob.glob(pathname, *, recursive=False) > > > > Return a possibly-empty list of path names that match pathname, > > which must be a string containing a path specification. pathname > > can be either absolute (like /usr/src/Python-1.5/Makefile) or > > relative (like ../../Tools/*/*.gif), and can contain shell-style > > wildcards. Broken symlinks are included in the results (as in > > the shell). Whether or not the results are sorted depends on the > > file system. > You are reading this correctly. > > So Git-style root-directory-only .srcignore files will do for SRC. > > Which doesn't surprise me at all, because SRC in general copycats > > Git's behavior in many aspects. > However, your conclusion is unfounded. You need a root directory and > recursion for Git-style glob patterns. > > SRC is RCS/SCCS revisited with a modern frontend. It is - just like > RCS and SCCS - not recursive. None of its commands work recursively. When I actually try this, I see something that confirms my understanding: ~$ mkdir src_vcs ~$ cd src_vcs ~/src_vcs$ mkdir .src ~/src_vcs$ touch file1 ~/src_vcs$ mkdir t1 ~/src_vcs$ touch t1/file1 ~/src_vcs$ src status t1/file1 ? t1/file1 ~/src_vcs$ cat > .srcignore t1/file1 ^D ~/src_vcs$ src status t1/file1 I t1/file1 ~/src_vcs$ src status -a ? .srcignore ? file1 ? t1 > There is also no notion of a root directory, i.e. SRC **never** checks > a parent directory for ignore patterns, which would be necessary for a > Git-style glob to work. The first part is true, but if we invoke "src status" from the root directory, the .srcignore file there will be read, and as the example above shows, will have its effect. Right? > >>> Roughly and handwavy, we can take this case to mean "use default-directory". > >> Unfortunately not. If the file or pattern to be ignored is in a > >> subdirectory of default-directory, the DIRECTORY argument must reflect > >> this for CVS, SVN, SRC. > > But since CVS and SVN don't use vc-default-ignore, and SRC can do with > > a single file in the root of the repository, does it really matter in > > practice? > > IMHO, the goal should be to eliminate both vc-svn-ignore and > vc-cvs-ignore, replacing the functionality by low-level backend > functions, which is perfectly possible, iff the ignore file / ignore > directory is correctly identified: vc-cvs-find-ignore-file, > vc-svn-ignore-file (just to identify the directory), vc-svn-add-line, > vc-svn-remove-line (or a combined handler for addition and > removal). This also results in cheap ignore file support for SRC with > a single function vc-src-find-ignore-file. I don't see how this answers my question, sorry. Even if our long-term goal is to remove vc-svn/cvs-ignore-file (which are already backend functions, of course), my question is still valid and interesting under the current situation, to which Dmitry's suggestion above pertained, AFAIU. So we might consider his suggestion "good enough" under the current situation.