On 11/2/2021 11:33 AM, Ævar Arnfjörð Bjarmason wrote: > > We have t3070-wildmatch.sh testing various combinations of these, and > indeed this code resolves back to wildmatch(). > > But I think in this case this is due to dir.c's particular behavior of > splitting paths before feeding them to wildmatch, as it needs to match > things relative to the subdirectory. > > Still, we've got a matrix of these in t3070-wildmatch.sh, which already > tests some (but apparently not all) cases where we need to create an > actual file on disk. These sorts of test blindspots are why I added that > in de8bada2bf6 (wildmatch test: create & test files on disk in addition > to in-memory, 2018-01-30). > > Wouldn't it be better & more exhaustive here to change its test lines > like: > > > match 0 0 1 1 foo/bar/baz 'bar' > > To say: > > match 0 0 1 1 ? ? foo/bar/baz 'bar' > > And just add to its match() function so that if we have a subject with a > slash, we mkdir up to that first slash (here: "mkdir foo"), and create a > .gitignore file therein with the "foo" directory with the "bar" content, > perhaps adding "/bar", "bar/" and "/bar/" variants implicitly. > > Then create a "bar.txt" in the directory as well, and a > bar-otherdir/somefile.txt or whatever. > > And fill in the "? ?" depending on whether those variants matched or > not... > > Anyway, just an idea, but if you pursue that you should be able to get > much more exhaustive testing in this area that we've apparently had a > blindspot in. Those tests are quite exhaustive, but the test script is pretty inscrutable and the refactor you suggest is pretty major. I'd prefer to keep to the focused test for the sake of fixing this in time for the release. Thanks, -Stolee
