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

[Eli Zaretskii <eliz@gnu.org>]

> Cc: dgutov@yandex.ru, 37189@debbugs.gnu.org
> From: Wolfgang Scherer <Wolfgang.Scherer@gmx.de>
> 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.