Question — manifest.json absolute paths + missing graphify-out/.gitignore: intended or oversight?

[gnrlbzik]

Observation 1 — manifest.json paths

save_manifest() in graphify/detect.py (verified on 0.7.5, lines 760-771) writes file paths as dict keys (manifest[f] = {...}), where f originates from os.walk over the absolute root and is never relativized. Result: graphify-out/manifest.json contains entries like:

{
  "/Users/<name>/Projects/<repo>/packages/types/src/portfolio.ts": {
    "mtime": 1771971357.10,
    "hash": "3743c6e8a0c40024bccbaa7499cf547d"
  }
}

Note: graph.json source_file paths were relativized in 0.5.0, but the same change wasn't applied to manifest.json.

Observation 2 — no default .gitignore shipped

graphify-out/ is created on first run but contains a mix of:

• Shareable artifacts — graph.json, GRAPH_REPORT.md, wiki/, cost.json, graph.html
• Per-developer state — all of which contain absolute paths or per-machine values:
  • manifest.json — incremental detect cache (detect.py:save_manifest, absolute path keys + mtime + hash)
  • .graphify_root — saved scan-root (absolute path; __main__.py:1563, watch.py:133)
  • .graphify_incremental.json — incremental detect cache (absolute path keys)
  • .graphify_python — venv interpreter path (absolute)
  • .graphify_detect.json — transient detect output cache (absolute paths; __main__.py:1880)

Consumers must manually figure out which files are local-state vs. shareable, or end up tracking the wrong set. We hit this — manifest.json was committed and started leaking absolute /Users/<name>/... paths across the team.

Questions

1. Is keeping absolute paths in manifest.json intended (e.g. cross-machine portability not a goal because it's local cache only)?
2. If absolute paths aren't intended, would you accept a PR that relativizes manifest.json keys against the root, matching graph.json's 0.5.0 behavior?
3. Would you consider shipping a default .gitignore (or README guidance) under graphify-out/ listing which files are local-state and shouldn't be committed? With five separate per-machine files, this is non-obvious without reading the source.

Happy to open a PR for either if intent is "oversight, fix accepted."

Environment

• graphifyy 0.7.5
• Python 3.13
• Project layout: knowledge/graphify/.venv + graphify-out/ colocated under a project subdir

[gianlucapisati]

I've got the same question about the absolute path.
It would be very useful to push these files to remote and share them with the team

[xuanswe]

Absolute paths are used everywhere:

• git hooks: post-checkout, post-commit
• GRAPTH_REPORT.md
• graph.json
• manifest.json
• cache/*.json

This prevents working in multiple machines or in a team :(.

Claude Code suggests: gitignore graphify-out/ completely :(

[onionhammer]

Seems like kinda a critical issue given the git support this repo has

[edgarlepe]

It looks like the library side of this was fixed by #1125 (for #777), but the shipped skill files never opt into it, so the default agent-driven pipeline still writes absolute-keyed manifests.

save_manifest() / load_manifest() now accept root= and relativize keys. However, none of the bundled skill instructions pass it.

[pydentity]

It's even worse:
I renamed the dir of my repo. After a while I ran a /graphify update. It rescanned the whole repo and now I have all files duplicated in my manifest.json. Version 0.8.39.

How is sharability/portability of generated graphs not a number 1 priority? Absolutely baffling.