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

From: Kyle Meyer <kyle@kyleam.com>
Date: Dec 8, 2019, 05:31 UTC
Message-ID: <871rtfv0wn.fsf@kyleam.com>
In-Reply-To: <874kyf6en3.fsf@kyleam.com>

Kyle Meyer <kyle@kyleam.com> writes:

Show 18 quoted lines

> 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/