Matheus Tavares Bernardino <matheus.bernardino@xxxxxx> writes: >> 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. I do not offhand know the answers to these questions you ask in the last paragraph myself, and it could turn out to be that the "let processing go as before, matching what those excluded paths by the matcher, but making the caller responsible for filtering out the paths excluded by sparcity out of the result from the matcher, but tweak seen[]" approach, however ugly, is the most practical, after your investigation. But I'd prefer to see how bad the situation is first ;-). Thanks.
