Re: [PATCH v3 5/7] refresh_index(): add REFRESH_DONT_MARK_SPARSE_MATCHES flag
- From
Matheus Tavares Bernardino <matheus.bernardino@usp.br>
- Date
- Mar 19, 2021, 12:23 UTC
- Message-ID
- <CAHd-oW4V4_XrY7XfQO1gLEZZmzcLbG0_M2ys+Meh4Ysu0Psz0Q@mail.gmail.com>
- In-Reply-To
- <xmqqo8fgovuz.fsf@gitster.g>
On Thu, Mar 18, 2021 at 9:00 PM Junio C Hamano <gitster@pobox.com> wrote:
Show 23 quoted lines
> > Junio C Hamano <gitster@pobox.com> writes: > > > Matheus Tavares <matheus.bernardino@usp.br> writes: > > > >> refresh_index() optionally takes a seen[] array to mark the pathspec > >> items that had matches in the index. This is used by `git add --refresh` > >> to find out if there was any pathspec without matches, and display an > >> error accordingly. > > > > It smells a bit iffy in that this allows a path to "match" a pattern > > but yet not result in seen[] to record that the pattern participated > > in the match. If the series is working towards certain operations > > not to touch paths that are outside the sparse checkout, shouldn't > > it be making these paths not to match the pattern, and by doing so > > it would automatically cause the pattern to be considered "not yet > > matching any path" when the matcher attempts to match the pattern to > > such a path? > > In other words, the change makes me wonder why we are not adding a > flag that says "do we or do we not want to match paths outside the > sparse checkout cone?", with which the seen[] would automatically > record the right thing.
Yeah, makes sense. I didn't want to make the flag skip the sparse paths unconditionally (i.e. without matching them) because then we would also skip the ce_stage() checkings below and the later ce_mark_uptodate(). And I wasn't sure whether this could cause any unwanted side effects.
But thinking more carefully about this now, unmerged paths should never have the SKIP_WORKTREE bit set anyway, right? What about the CE_UPTODATE mark, would it be safe to skip it? I'm not very familiar with this code, but I'll try to investigate more later.