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.

> 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.

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.