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

[Kyle Meyer <kyle@kyleam.com>]

Hi Elijah,

Thanks for the detailed and helpful reply.

Elijah Newren <newren@gmail.com> writes:

[...]

> As you mentioned, it won't traverse into it even when specified...
>
> $ git ls-files -o untracked_repo/
> untracked_repo/empty
>
> ...except that it does traverse into this directory if the user tab
> completes the name or otherwise manually adds a trailing slash.

Ah yes, I recall encountering what I think is the same underlying issue
when working on a previous series [0,1].  In the context of 'git add
untracked_repo/', there's been some discussion related to this trailing
slash discrepancy at

  https://lore.kernel.org/git/20180618111919.GA10085@book.hvoigt.net/T/#u

> Weird, let's try multiple pathspecs:
>
> $ git ls-files -o untracked_dir untracked_repo
> untracked_dir/empty
> untracked_repo/
>
> $ git ls-files -o untracked_dir untracked_repo/
> untracked_dir/empty
> untracked_repo/
>
> So it will traverse into the untracked_repo when specified as
> 'untracked_repo/' but not if there are more than one pathspec given?!?

Eh, indeed.

>  And it traverses into an untracked directory regardless of the
> trailing slash?  <sarcasm>What a paragon of consistency...</sarcasm>
>
>
> 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

> As for whether that's desirable or not when the pathspec is a submodule,
> I'm not certain. [...]
>
> But here are some possibilities that at least sound sane:
>
> A) ls-files -o should traverse into untracked submodules.  This case
> is easy; the code already does that.

Hmm, but as shown in the last example, ls-files -o doesn't traverse into
untracked submodules for the single pathspec case.

> B) ls-files -o should NOT traverse into untracked submodules AND
> should not even report them.
>
> C) ls-files -o should NOT traverse into untracked submodules, but
> should at least report their directory name.  If so, the fix is
> [...]

This behavior---which matches the no-slash behavior when no patchspec or
a single pathspec is given (on both v2.24.0 and previous version) as
well as when multiple pathspecs are given (before v2.24.0)---is the one
I prefer.  My biased reason for this preference is that in the DataLad
project we identify untracked nested repositories based on `ls-files -o
<untracked directory>...` reporting only the directory name for
repositories.  (Looking into one of our tests that fails with Git
v2.24.0 is how I ran into the reported change in behavior [2].)

That some external project relies on unintended ls-files output of
course doesn't mean that Git should keep reporting things that way, but
it does mean that I _hope_ that not traversing into untracked
repositories is the intended behavior and that traversing (either
because a slash is appended or as of 89a1f4aaf7 because multiple
pathspecs are given) is not intended :>


[0]: https://lore.kernel.org/git/20190409230737.26809-1-kyle@kyleam.com
[1]: https://lore.kernel.org/git/87bm1mbua4.fsf@kyleam.com/
[2]: https://github.com/datalad/datalad/issues/3890#issuecomment-561722194