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

[Elijah Newren <newren@gmail.com>]

On Sat, Dec 7, 2019 at 9:42 PM Elijah Newren <newren@gmail.com> wrote:
>
> Hi Kyle,
>
> On Sat, Dec 7, 2019 at 9:31 PM Kyle Meyer <kyle@kyleam.com> wrote:
> >
> > 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/
>
> Yeah, I spotted that too.  You left out a case, a single pathspec with
> the trailing slash:
>
>    git ls-files -o --directory untracked_dir/
>
> That will traverse into the directory before or after my changes.  I
> also spotted a few other bugs, e.g. try out 'git ls-files -o .git/'
> (with either git-2.23 or git-2.24).  Whoops.  We do correctly avoid
> traversing into the .git directory if multiple pathspecs are provided.
> Anyway, this whole area seems to be a bug factory.  Every time I think
> I'm close to having some patches to send to the list to fix up the
> issues I've found, I find the fix isn't where I thought it was and/or
> find yet another bug.  Quite aggravating.
>
> I'm thinking of just sending the patches I have, since they fix up all
> the issues we've discussed so far (including the .git/ case I just
> mentioned), and ignoring the 2-3 other bugs I found that are still
> broken other than providing testcases documenting their breakage.

If you want to take an early look, I've got some patches up at
https://github.com/git/git/pull/676.  I plan to write a proper cover
letter and submit to the list on Monday.