Re: [BUG?] ls-files -o now traverses nested repo when given multiple pathspecs

>
> Kyle Meyer <kyle@kyleam.com> writes:
>
> > Elijah Newren <newren@gmail.com> 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/