From: Stefan Sperling Subject: Re: leading separators in ignore patterns To: Evan Silberman Cc: gameoftrees@openbsd.org Date: Mon, 12 May 2025 11:01:13 +0200 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.