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 2026年8月30日 at 15:25, Junio C Hamano <gitster@xxxxxxxxx> wrote: > > "Diogo Castro via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > > > From: Diogo Castro <dc@xxxxxxxxxxxxxxx> > > > > `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. >