In general, our pattern matching in this library doesn't match Git's behavior. We should overhaul our pattern matching such that it does indeed match, ensure that we have options for both gitignore and gitattributes, and add sufficient tests.

One approach that may be interesting is to convert to a regex-based implementation, although a less dramatic overhaul preserving the current code is also a possibility.

There are a couple of cases where the functionality of wildmatch differs from the .gitattributes style match. This is concerning the end of match strings. There are actually two cases.

The first is when the match string ends in a /, indicating a directory. This will incorrectly match a non-directory file. For example, the search string file.txt/ will match file.txt.

The other case is that /** double star endings, would match files in a similar way to above. So for example, file.txt/** matches file.txt.

@larsxschneider wisely points out in 5d24d97#r27205600:

AFAIK Git's pattern matching also depends on the file system in use. E.g. foo would match FOO on macOS and Windows but not on Linux with a case sensitive file system. Would it be useful in downstream projects if Match() had an additional parameter that defines case sensitivity?

I agree that this would be useful functionality. I am considering changing the API in the following manner:

type opt func(w *Wildmatch)

var CaseSensitive opt
var CaseInsensitive opt
var FilesystemSensitivity opt

func New(pattern string, opts ...opt) *Wildmatch { ... }

Which will allow the user to opt in to case insensitivity, or defer to the filesystem.

As mentioned in git-lfs/git-lfs#3406, we incorrectly consider **/*/unicorns/*.bin not to match data/rainbows/unicorns/0ee357d9-bc00-4c78-8738-7debdf909d26.bin, although the pattern **/unicorns/*.bin does work.

We should update this pattern such that both patterns match that string.