Hey everyone,
One of the most common pain points I kept hearing about: graphify works great on a solo project, but once you have multiple people committing, things get messy. graph.json ends up with conflict markers, two devs rebuild from the same code and get different community IDs, renamed files blow away the cache. This release fixes all of that.
What's new
No more merge conflicts in graph.json
Run graphify hook install once in your repo. It now sets up a git merge driver that union-merges two graph.json files automatically. When two teammates commit at the same time and git tries to merge their graphs, it just combines the nodes and edges from both sides. No conflict markers, no manual resolution, nothing to think about.
It also writes the right .gitattributes entry and registers the driver in .git/config for you.
Deterministic community IDs
Leiden community detection is now seeded. Before this, two people rebuilding the graph from identical code could get different community numbers, which meant a 500-node diff for a 2-line code change. Now parallel rebuilds produce the same output.
Renamed files reuse their cache
The file hash used to include the file path, so renaming utils.py to helpers.py would invalidate the cache and re-extract the whole file. Now it's content-only. Rename 50 files in a refactor and the cache still hits.
Graph freshness signal
graph.json now records which git commit it was built from. GRAPH_REPORT.md shows the short hash so your AI assistant (or you) can compare against git rev-parse HEAD and know if the graph is stale before answering architecture questions.
Mixed code/doc commits handled correctly
If a commit touched both Python files and markdown docs, watch mode used to skip the code rebuild entirely. Now it rebuilds the code immediately and queues the docs for LLM re-extraction separately.
How to get it
pip install --upgrade graphifyy
or
uvx graphifyy
Then run graphify hook install in your repo to set up the merge driver and post-commit hooks.