Problem
In a monorepo or multi-repo workspace, there is no single command to update all per-repo graphify-out/ graphs at once. The only option today is to call graphify update <path> individually for each sub-repo, which for a 14-repo workspace requires either a shell loop or spawning parallel agents manually.
Proposed command
graphify update . --recursive
Walk the directory tree from <path>, discover every subdirectory that contains a graphify-out/.graphify_root marker file, and run the equivalent of graphify update <sub-path> for each one in parallel.
Optional flags that would pair well:
--force: propagate to all sub-repos (same semantics as the single-path --force)
--concurrency N: cap parallel workers (default: cpu count or some reasonable limit)
- A summary table at the end: repo name | nodes | edges | communities | status
Current workaround
Spawn N parallel agents (one per repo) or write a shell loop:
find . -name '.graphify_root' -path '*/graphify-out/*' | while read f; do
dir=$(dirname $(dirname "$f"))
graphify update "$dir" &
done
wait
This works but produces interleaved output and has no built-in concurrency cap.
Workspace that motivated this
14-repo workspace under a single parent directory. Running the parallel-agents workaround took ~90 seconds wall-clock and required external orchestration. A first-class --recursive flag would make this a one-liner with clean per-repo output.
Problem
In a monorepo or multi-repo workspace, there is no single command to update all per-repo
graphify-out/graphs at once. The only option today is to callgraphify update <path>individually for each sub-repo, which for a 14-repo workspace requires either a shell loop or spawning parallel agents manually.Proposed command
Walk the directory tree from
<path>, discover every subdirectory that contains agraphify-out/.graphify_rootmarker file, and run the equivalent ofgraphify update <sub-path>for each one in parallel.Optional flags that would pair well:
--force: propagate to all sub-repos (same semantics as the single-path--force)--concurrency N: cap parallel workers (default: cpu count or some reasonable limit)Current workaround
Spawn N parallel agents (one per repo) or write a shell loop:
This works but produces interleaved output and has no built-in concurrency cap.
Workspace that motivated this
14-repo workspace under a single parent directory. Running the parallel-agents workaround took ~90 seconds wall-clock and required external orchestration. A first-class
--recursiveflag would make this a one-liner with clean per-repo output.