From: Elijah Newren <newren@gmail.com>
To: Kyle Meyer <kyle@kyleam.com>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: [BUG?] ls-files -o now traverses nested repo when given multiple pathspecs
Date: Sat, 7 Dec 2019 21:42:00 -0800 [thread overview]
Message-ID: <CABPp-BEvr+wB_yqOAG9oOaONtckYzn-zghyAtx2fWJweg55ovA@mail.gmail.com> (raw)
In-Reply-To: <871rtfv0wn.fsf@kyleam.com>
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.
next prev parent reply other threads:[~2019-12-08 5:42 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-03 22:08 [BUG?] ls-files -o now traverses nested repo when given multiple pathspecs Kyle Meyer
2019-12-04 17:30 ` Elijah Newren
2019-12-04 19:42 ` Junio C Hamano
2019-12-04 20:04 ` Kyle Meyer
2019-12-08 5:31 ` Kyle Meyer
2019-12-08 5:42 ` Elijah Newren [this message]
2019-12-08 7:46 ` Elijah Newren
2019-12-08 22:59 ` Kyle Meyer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CABPp-BEvr+wB_yqOAG9oOaONtckYzn-zghyAtx2fWJweg55ovA@mail.gmail.com \
--to=newren@gmail.com \
--cc=git@vger.kernel.org \
--cc=kyle@kyleam.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).