graphify ignores `.git/info/exclude` — indexes git-worktree dirs, causing massive graph bloat

[cdahl86-cyber]

Summary

graphify builds its ignore set only from .gitignore and .graphifyignore (detect.py, _load_graphifyignore iterates exactly (".gitignore", ".graphifyignore")). It does not read .git/info/exclude — the standard place git records git-worktree paths and local-only excludes. As a result graphify walks into git-worktree directories nested under the repo (each a full second copy of the codebase) and the graph explodes.

Repro

1. A repo with git worktrees checked out under it, e.g. worktrees/foo, excluded via .git/info/exclude (not .gitignore).
2. graphify update . (or the graphify hook install auto-rebuild hooks) walks into worktrees/* and indexes every copy.

In my case (5 worktrees) the graph went from ~9,400 nodes / 10 MB to ~210,000 nodes / 311 MB — ~77% duplicate worktree nodes, near the 512 MB graph.json cap — and it was regenerated on every commit by the auto-rebuild hooks.

Version

graphifyy 0.9.12

Suggested fix

Include .git/info/exclude in the ignore set (or, more robustly, defer to git check-ignore semantics when inside a git repo). At minimum, document that only .gitignore / .graphifyignore are honored, so users know to add worktree dirs there.

Workaround

Add the worktree directory to .gitignore or .graphifyignore.

[safishamsi]

Fixed in 5f57c46 (ships in 0.9.14). Detection now reads .git/info/exclude in addition to .gitignore/.graphifyignore, loaded at lowest precedence (below every per-directory ignore file, matching git — so a nearer ! re-include still wins). The linked-worktree/submodule case (where .git is a file pointing at a gitdir) is resolved to the shared common git dir, so info/exclude is found there too. Verified against a repo whose worktree dir was excluded only via info/exclude: the worktree copy is no longer indexed, real source is kept. Thanks for the precise diagnosis and the before/after node counts, @cdahl86-cyber.