git_aware=true on the mounts listing filters out .gitignore-matched entries, but its ignore semantics are best-effort, not Git-compatible, in two verified ways. Before we either fix or document this, we need a product decision: does git_aware=true promise Git-compatible ignore semantics, or is it an explicitly best-effort presentation filter? The answer decides whether the two gaps below are bugs to fix or behavior to document (and possibly rename the flag).
Verified gaps on the branch tip (api/oss/src/core/mounts/service.py):
- Cross-file
!negation is never consulted. _path_gitignored walks the ancestor chain and returns True on the first matching spec, with specs ordered shallow-to-deep. So a deeper .gitignore's !re-include rule can never override a shallower ignore. Negation works within a single .gitignore file (pathspec handles it) but not across files — the docstring admits it.
with_counts child counts use the wrong spec set. _count_children filters with the parent's ancestor-chain specs (captured in the enclosing _keep closure) and never loads the child directory's own .gitignore. So a folder's badge count can disagree with what expanding that folder actually shows.
The goal is a documented contract for git_aware, then the code brought into line with it.
Follow-up from the #5400 backend review; needs a product decision before implementation. Cited finding: 3.2 ("git-aware" is quietly best-effort — cross-file negation is not honored and with_counts counts use only the parent's specs, so the same file can be hidden in one view and visible in another). (The paged-cursor polish originally bundled here is dropped — the paged listing was removed from the branch.) The review report is not in the repo, so this summary stands alone.
git_aware=trueon the mounts listing filters out.gitignore-matched entries, but its ignore semantics are best-effort, not Git-compatible, in two verified ways. Before we either fix or document this, we need a product decision: doesgit_aware=truepromise Git-compatible ignore semantics, or is it an explicitly best-effort presentation filter? The answer decides whether the two gaps below are bugs to fix or behavior to document (and possibly rename the flag).Verified gaps on the branch tip (
api/oss/src/core/mounts/service.py):!negationis never consulted._path_gitignoredwalks the ancestor chain and returnsTrueon the first matching spec, with specs ordered shallow-to-deep. So a deeper.gitignore's!re-includerule can never override a shallower ignore. Negation works within a single.gitignorefile (pathspec handles it) but not across files — the docstring admits it.with_countschild counts use the wrong spec set._count_childrenfilters with the parent's ancestor-chain specs (captured in the enclosing_keepclosure) and never loads the child directory's own.gitignore. So a folder's badge count can disagree with what expanding that folder actually shows.The goal is a documented contract for
git_aware, then the code brought into line with it.with_countschild-spec scope. If best-effort: document the limitation and consider renaming the flag to signal it.Follow-up from the #5400 backend review; needs a product decision before implementation. Cited finding: 3.2 ("git-aware" is quietly best-effort — cross-file negation is not honored and
with_countscounts use only the parent's specs, so the same file can be hidden in one view and visible in another). (The paged-cursor polish originally bundled here is dropped — the paged listing was removed from the branch.) The review report is not in the repo, so this summary stands alone.