Repository navigation
Github diff too large for commited graphify-out content #3413
Description
I found useful to setup our .gitattributes file for 4 commited graphify files as:
graphify-out/graph.json merge=graphify
graphify-out/** linguist-generated
# Skip line-level diffing for the auto-regenerated graph artifacts: git treats each version as
# opaque binary for diff purposes instead of running the LCS algorithm over it. graph.json is
# pretty-printed and can show 1M+ changed lines between rebuilds (node ordering shifts), which
# blows past GitHub's diff-generation time budget - the PR /files and /compare endpoints then
# fail with HTTP 422 ("Sorry, this diff is taking too long to generate.") and the PR page/API
# silently report 0 changed files across the whole PR instead of surfacing the error.
# linguist-generated above only collapses the *rendered* diff in the UI; it still has to be
# computed first, so it alone does not fix this. The other three files here are smaller but
# regenerate the same way on every commit, so they get the same treatment pre-emptively.
graphify-out/graph.json -diff
graphify-out/manifest.json -diff
graphify-out/GRAPH_REPORT.md -diff
graphify-out/.graphify_labels.json -diff
though the GitHub's files changed tab shows 0 - as the diff got too large
Any solution how to setup Github diff properly - to ignore the graphify-out content?
Activity
SinghAman21 commentedon Sep 13, 2026
try committing after 2-3 prompts to keep the git diff check under control.
maybe you handed over a large task to agent which caused this huge change, could be one time thing as well ( just my speculation )
dej-h commentedon Sep 20, 2026
I ran into this in a repository where we commit the generated Graphify output.
We first tried essentially the approach proposed here and in #3575: marking the generated files with -diff and linguist-generated. That did not reliably solve the GitHub PR totals problem for us. It changes how files are displayed, but still leaves the solution dependent on GitHub honoring those attributes while processing the generated text.
We ended up replacing the individually tracked graph files with a deterministic ZIP snapshot.
Our hook:
Git consequently treats the snapshot as a single binary file. In our verification, git show --numstat reports - - for it and the commit reports zero text insertions and deletions. This avoids generated graph lines contributing to PR totals without requiring any manual graph maintenance.
The relevant history in our repository is:
I am happy to extract the implementation into a minimal reproduction or contribute an opt-in tracked snapshot mode. Would that fit as an extension of fix(export): give a committed output directory its diff attributes #3575, or would you prefer a separate feature proposal?
andrebrait commentedon Sep 30, 2026
Yeah, I remember it being solved for a while, but now the number of modified lines is back on counting the graph ones.
I am doing things slightly different so rather than using a post-commit hook I am actually using a pre-commit hook so every commit carries the changes made to the graph.
PR Graphify-Labs#4319: fix: write graph.json as one line of compact J…
PR Graphify-Labs#4319: fix: write graph.json as one line of compact J…
fix: write graph.json as one line of compact JSON (#3413)
safishamsi commentedon Oct 11, 2026
Fixed in 0.9.86 (now on PyPI) via #4319. Thanks @andrebrait!