Re: [RFC PATCH 4/7] dir: Directories should be checked for matching pathspecs too
- From
Elijah Newren <newren@gmail.com>
- Date
- Apr 5, 2018, 19:15 UTC
- Message-ID
- <CABPp-BEnFiEnao0NqU3GerYkpxO9fJadQLHo6_PZ-hXLZfbbdg@mail.gmail.com>
- In-Reply-To
- <20180405185805.GA21164@sigill.intra.peff.net>
On Thu, Apr 5, 2018 at 11:58 AM, Jeff King <peff@peff.net> wrote:
Show 9 quoted lines
> It sounds like correct_untracked_entries() is doing the wrong thing, and > it should be aware of the pathspec-matching when culling entries. In > other words, my understanding was that read_directory() does not > necessarily promise to cull fully (which is what led to cf424f5fd in the > first place), and callers are forced to apply their own pathspecs. > > The distinction is academic for this particular bug, but it makes me > wonder if there are other cases where "clean" needs to be more careful > with what comes out of dir.c.
Interesting, I read things very differently. Looking back at commit 6b1db43109ab ("clean: teach clean -d to preserve ignored paths", 2017-05-23), which introduced correct_untracked_entries(), I thought that correct_untracked_entries() wasn't there to correct pathspec issues with fill_directory(), but instead to special case the handling of files which are both untracked and ignored. Did I mis-read or were there other commits that changed the semantics?
Also, it would just seem odd to me that fill_directory() requires pathspecs, and it uses those pathspecs, but it doesn't guarantee that the files it returns matches them. That seems like an API ripe for mis-use, especially since I don't see any comment in the code about such an assumption. Is that really the expectation?