On Sat, Dec 7, 2019 at 9:42 PM Elijah Newren <newren@xxxxxxxxx> wrote: > > Hi Kyle, > > On Sat, Dec 7, 2019 at 9:31 PM Kyle Meyer <kyle@xxxxxxxxxx> wrote: > > > > Kyle Meyer <kyle@xxxxxxxxxx> writes: > > > > > Elijah Newren <newren@xxxxxxxxx> writes: > > >> [...] > > >> At least my changes in git-2.24.0 made the behavior consistent; it'll > > >> always traverse into a directory that matches a given pathspec. > > > > > > I might be getting mixed up, but the changes in 2.24.0 did introduce > > > some inconsistent behavior (in the no trailing slash case) with respect > > > to giving a single pathspec and giving multiple pathspecs, no? Using > > > your example: > > > > > > $ git --version > > > git version 2.24.0 > > > $ git ls-files -o untracked_repo > > > untracked_repo/ > > > $ git ls-files -o untracked_repo empty > > > empty > > > untracked_repo/ > > > untracked_repo/empty > > > > It looks like the "multiple pathspecs trigger traversal" change isn't > > limited to nested repositories. It can also be observed with > > --directory and plain untracked directories. Assume the tree layout > > from your example again. With a single pathspec (and no slash), > > 'ls-files -o --directory' will not expand the untracked directory's > > contents: > > > > $ git ls-files -o --directory untracked_dir > > untracked_dir/ > > > > But, as of 89a1f4aaf7, tacking on an additional pathspec will cause > > ls-files to traverse into the untracked directory: > > > > $ git ls-files -o --directory untracked_dir empty > > empty > > untracked_dir/ > > untracked_dir/empty > > > > In contrast, on 89a1f4aaf7^ the same command shows > > > > $ git ls-files -o --directory untracked_dir empty > > empty > > untracked_dir/ > > Yeah, I spotted that too. You left out a case, a single pathspec with > the trailing slash: > > git ls-files -o --directory untracked_dir/ > > That will traverse into the directory before or after my changes. I > also spotted a few other bugs, e.g. try out 'git ls-files -o .git/' > (with either git-2.23 or git-2.24). Whoops. We do correctly avoid > traversing into the .git directory if multiple pathspecs are provided. > Anyway, this whole area seems to be a bug factory. Every time I think > I'm close to having some patches to send to the list to fix up the > issues I've found, I find the fix isn't where I thought it was and/or > find yet another bug. Quite aggravating. > > I'm thinking of just sending the patches I have, since they fix up all > the issues we've discussed so far (including the .git/ case I just > mentioned), and ignoring the 2-3 other bugs I found that are still > broken other than providing testcases documenting their breakage. If you want to take an early look, I've got some patches up at https://github.com/git/git/pull/676. I plan to write a proper cover letter and submit to the list on Monday.
