From: Evan Silberman <evan@jklol.net>
Subject: Re: leading separators in ignore patterns
To: Stefan Sperling <stsp@stsp.name>
Cc: gameoftrees@openbsd.org
Date: Mon, 12 May 2025 11:15:43 -0700

Stefan Sperling <stsp@stsp.name> wrote:
> On Sat, May 10, 2025 at 03:39:00PM -0700, Evan Silberman wrote:
> > got(1) status says it "gives no special significance to the location of
> > path component separators in a pattern", i.e. it doesn't implement the
> > rule from gitignore(7) that "if there is a separator at the beginning or
> > middle of the pattern, then the pattern is relative to the directory
> > level of the particular .gitignore file itself. otherwise the pattern
> > may also match at any level below the .gitignore level".
> 
> Rather than phrasing this issue as "Got does what Git does except
> differently", we should probably say outright that Got uses fnmatch.
> (With one extension which makes ** patterns work to allow files in
> subdirectories to be matched.)
> 
> So we get fnmatch behaviour. Calling into fnmatch is a simple, effective,
> and portable pattern matching solution. Of course, we don't get Git's
> custom matching engine with its special semantics. The upside is that we
> aren't forced to reimplement it and write our own tests for such an engine.

Quite so.

> > An infelicity of this is that it means that .gitignore patterns like
> > '/build' will never be ignored by got. From what I can tell, I think got
> > could reasonably treat any '/pattern' identically to 'pattern'. In so
> > doing, got should ignore strictly more paths than it did before, without
> > ignoring any paths that git does *not* ignore using the same pattern.
> > 
> > I don't have a patch; I tried doing `if (line[0] == "/") line++;` in
> > read_ignores but apparently that's the wrong answer.
> 
> We could of course hack around the fnmatch behaviour. But is that really
> worth the effort? Every behaviour change affects regression tests which
> need to be tweaked, documentation which needs updates, etc.

> You've found that a simple change didn't immediately provide the desired
> result, and you stopped there. This indicates that solving this issue in
> Got itself isn't worth the resulting maintenance effort to you. We would
> need a complete patch with tests and documentation updates, and would
> need to keep maintaining this going forward.

Yeah I can try again, the result I got was a segfault (on mac on
-portable) so I didn't really want to start writing fancier code without
checking in about it. Also every(?) regress was failing on my checkout
so it would've been frustrating to actually regress my change. If I can
come up with something simple that does work and doesn't regress
anything I'll check back in with a patch.

> So far, whenever it has been pointed out that some specific pattern won't
> match there was an alternative pattern which does match and works in both
> systems. So tweaking ignore patterns might help, or amending them somehow
> (e.g. by adding a local .cvsignore file) might help. If that is good enough
> for you then I am happy enough with that we have.

I was going to allege that tweaking the .gitignore of a git-centric
upstream might be a non-starter but then I remembered that has nothing
to do with why I wrote this email in the first place so I won't harp on
it. Using .cvsignore with .cvsignore in it is probably an adequate
replacement for .git/info/exclude though!

Evan