GNU bug report logs - #37189
25.4.1: vc-hg-ignore implementation is missing

Previous Next

Full log

Message #155 received at 37189 <at> debbugs.gnu.org (full text, mbox):

From: Wolfgang Scherer <Wolfgang.Scherer <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 37189 <at> debbugs.gnu.org, dgutov <at> yandex.ru
Subject: Re: bug#37189: 25.4.1: vc-hg-ignore implementation is missing
Date: Sat, 22 Feb 2020 14:46:16 +0100

Am 22.02.20 um 08:44 schrieb Eli Zaretskii:
>> Cc: 37189 <at> debbugs.gnu.org
>> From: Wolfgang Scherer <Wolfgang.Scherer <at> gmx.de>
>> Date: Fri, 21 Feb 2020 23:22:18 +0100
>>
>>> Now, one could argue that one use case is more important than the other one, and that vc-ignore has for a while been geared toward entering plain file names rather than glob patterns. I have little opinion on this subject, however, since I mostly edit ignore files by hand, and do so very rarely. So as far as I'm concerned, we could remove this feature altogether and not lose much.
>> 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?

When files are properly escaped, it is possible to emulate patterns by
ignoring all matching files separately without knowing the exact
pattern syntax. This reduces the effort to marking the appropriate files
and pressing  C-u G  in vc-dir-mode.

The other way around is a lot harder, since it fails without a working
knowledge of ignore patterns in the context of a specific VCS. As you
demonstrate below for SRC.

My personal strategy with Mercurial has been to use the ignore file
feature (in DVC) to get a properly escaped file path, then edit
 .hgignore  to modify the full path to work as a pattern. So, yes I
can do very well without the pattern use case, but not really without
the file path 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.

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.

Here is a quote from SRC's mission statement:

http://www.catb.org/~esr/src/FAQ.html:

    You are certainly free to suggest features, but SRC is developed
    with extreme conservatism as to what features to implement or
    not. Remember, single-file, single-user, private VCS.

This means implicitely, that there is no recursion into
sub-directories by design. The  vc  package just emulates recursive
operation for RCS, SCCS, SRC. This works fine for RCS and SCCS, since
RCS can be invoked on files in a subdirectory and works properly,
e.g.:

    rcs log sub/data

However, SRC currently fails in that scenario, actually destroying the
repository identity. Which also means, that operations on
sub-directories in  vc-dir-mode  fail destructively. I have not yet
reported this issue for Emacs, but to ESR at
https://gitlab.com/esr/src/issues/14, to see, whether SRC can be
repaired.

If SRC is not repaired, it would probably be best to disable recursive
operations in  vc , since the patch to repair  vc-src.el  is a bit
ugly and the result is not even close to perfect
(https://gitlab.com/esr/src/uploads/ca532d65dbb07afcb2144afbded1b368/0001-Run-SRC-commands-separately-and-normalized-for-each-.patch).
>>> 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.

It also means, that escaping/anchoring does not have to be integrated
in 3 or 4 places but only once in vc-default-ignore or vc-ignore.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.