Hi Elijah,

Thanks for the detailed and helpful reply.

Elijah Newren [off-list ref] 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 (local)

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 (local)
[1]: https://lore.kernel.org/git/87bm1mbua4.fsf@kyleam.com/ (local)
[2]: https://github.com/datalad/datalad/issues/3890#issuecomment-561722194