Re: [PATCH] dir: fix negative pathspecs in 'git ls-files' and 'git add'

I don't think so.

As far as I can tell, the "strip the common prefix" feature is a
performance optimization aimed at avoiding walking the working
directory needlessly.
So for `git add -- a/b/c a/b/d`, there's no need to look anywhere
other than in `a/b/`.

But extending the "strip the common prefix" to negative pathspecs
could end up negating the benefits we get from this perf optimization.
E.g. in `git add -- a/b/c a/b/d ':!*.md'`, there is no prefix common
to *all* pathspecs, so we'd revert to walking the entire working
directory, even though `a/b/` would still suffice.


On Sun, 30 Aug 2026 at 15:25, Junio C Hamano [off-list ref] wrote:

"Diogo Castro via GitGitGadget" [off-list ref] writes:

quoted

From: Diogo Castro <redacted>

`git ls-files` calls `common_prefix()` / `get_common_prefix_len()` which
calculate the length of the common prefix of all *positive* pathspecs,
`max_prefix_len`.
...
Solution: in `do_match_pathspec()`, only strip the prefix when handling
positive pathspecs, not when handling negative pathspecs.

Hmph, if the command line were

        git ls-files -- a/b/c a/b/d !a/b/

shouldn't we strip a/b/ from all three?  Would it make sense to
leave the negative one relative to the full tree?  I am wondering
if the solution is to compute common prefix across both positive and
negative ones instead.