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

From: Kyle Meyer <[email-masked]>
Date: Sun, 08 Dec 2019 00:31:20 -0500

Kyle Meyer <[email-masked]> writes:

> Elijah Newren <[email-masked]> 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/