Question 1

Πώς διαχειρίζεται τα monorepos, τα git worktrees και πολλαπλά αποθετήρια;

Accepted Answer

Monorepos: δημιουργείται αυτόματα ένα γράφημα ανά ρίζα αποθετηρίου· ευρετηριάζονται μόνο τα παρακολουθούμενα αρχεία και ένα αρχείο .code‑review‑graphignore μπορεί να αποκλείσει πρόσθετες διαδρομές. Git worktrees: κάθε worktree ανιχνεύεται ως ξεχωριστή ρίζα και του αποδίδεται το δικό του γράφημα· η κοινή χρήση μιας μοναδικής βάσης δεδομένων μεταξύ worktrees σε διαφορετικές commit δεν υποστηρίζεται. Πολλαπλά αποθετήρια: ένα ελαφρύ μητρώο (αποθηκευμένο στο ~/.code‑review‑graph/registry.json) επιτρέπει στους πελάτες MCP να αναζητούν σε όλα τα καταχωρημένα έργα, και ένας δαίμονας μπορεί να παρακολουθεί αρκετά αποθετήρια για να διατηρεί τα γραφήματά τους ενημερωμένα. Χρησιμοποιήστε τις παραμέτρους --repo, --data-dir ή τη μεταβλητή περιβάλλοντος CRGDATADIR για προσαρμογή των τοποθεσιών.

Question 2

How big a codebase justifies it?

Accepted Answer

Below a few hundred files the benefit is marginal because an agent can often hold the whole repo in context. Between a few hundred and a few thousand files is the sweet spot: benchmarks on repos ranging from 60 to ~1,100 files show 38×–528× token reductions on whole‑corpus questions. Multi‑thousand‑file repos and monorepos provide the strongest case, as agents cannot read the entire corpus per query and incremental graph updates keep the index fresh with minimal cost. The frequency of multi‑file queries also influences the payoff.

Question 3

How do I verify it is working?

Accepted Answer

1. Ensure the graph file exists and contains nodes/edges; a zero count means the build didn’t run. 2. Run a change and observe the risk summary and Token Savings panel; add --verify to cross‑check token estimates with the cl100kbase tokenizer. 3. In Claude Code, run /mcp and confirm the code‑review‑graph server is connected and its tools are listed. Then ask a structural question (e.g., "what calls parsefile?") and verify the assistant uses query_graph instead of grepping. If any step fails, consult TROUBLESHOOTING.md.

Question 4

Does it phone home?

Accepted Answer

No. There is zero telemetry. The graph is stored locally in a SQLite file inside your repository, and all core operations run entirely on your machine. The only network activity is optional: installing the embeddings extra will download a sentence‑transformers model from HuggingFace, and cloud embedding providers (OpenAI, Google Gemini, MiniMax) will receive only the function signatures you explicitly choose to embed, after you acknowledge the egress warning. Otherwise, your code never leaves the machine.

Question 5

When should I not use it?

Accepted Answer

The README lists several cases: very small repos (a few hundred files) where the overhead of building a graph outweighs the benefits; trivial single‑file changes where the graph response adds more tokens than the raw diff; one‑off questions on a repo you won’t revisit; and flow detection in languages where CRG’s entry‑point detection is less reliable (e.g., JavaScript and Go currently have low recall). In these scenarios, simple agentic search or grepping is usually sufficient.

Question 6

How does it compare to Serena, codegraph, claude-context, and repomix?

Accepted Answer

These tools solve adjacent problems. code-review-graph builds a Tree‑sitter AST into a persistent SQLite graph with review‑focused edges (blast radius, risk‑scored change analysis, test‑gap detection). Serena uses LSP‑backed symbol retrieval and editing, focusing on editing rather than review. codegraph varies by implementation but generally provides AST/call‑graph indexing. claude-context offers chunk‑plus‑embed semantic code search using a vector store, suited for search rather than structural review. repomix packs an entire repo into a single AI‑friendly file without structural queries. Choose the tool based on whether you need precise editing (Serena), semantic search (claude-context), or review‑oriented structural analysis (code‑review‑graph).

Question 7

Γιατί να μην χρησιμοποιήσουμε απλώς το grep;

Accepted Answer

Το grep λειτουργεί για απλές ερωτήσεις ενός βήματος όπως «πού ορίζεται το parsefile;», αλλά δυσκολεύεται με ερωτήματα πολλαπλών βημάτων που απαιτούν διαδοχική ανίχνευση, χαρτογράφηση κάλυψης δοκιμών ή ανάλυση ακτίνας επιρροής. Κάθε επιπλέον βήμα θα απαιτούσε μια ακόμη εκτέλεση grep, αυξάνοντας τη χρήση tokens και δημιουργώντας ψευδώς θετικά αποτελέσματα από υπερφορτωμένα ονόματα. Το CRG απαντά σε αυτά με ένα μόνο ερώτημα γραφήματος, διατηρεί τη δεικτοδοτημένη δομή σε SQLite και ενημερώνεται σταδιακά, αποφεύγοντας την επαναλαμβανόμενη σάρωση και παρέχοντας ερωτήματα που δεν έχουν ισοδύναμο grep, όπως «ποιες διαδρομές εκτέλεσης επηρεάζει αυτή η αλλαγή».

Question 8

Isn't this just RAG?

Accepted Answer

Όχι. Το RAG χωρίζει τον κώδικά σας σε κομμάτια κειμένου, τα ενσωματώνει (embeds) και ανακτά τα κομμάτια με βάση τη ομοιότητα προς το ερώτημα. Δεν μπορεί να απαντήσει σε δομικά ερωτήματα όπως "ποιος καλεί το X" επειδή η ομοιότητα δεν εγγυάται ύπαρξη σχέσης κλήσης. Το CRG αποθηκεύει δομικές ακμές που εξάγονται από το AST — κλήσεις, imports, κληρονομικότητα, κάλυψη τεστ — έτσι ένα ερώτημα όπως "ποιος καλεί το login()" απαντάται με αναζήτηση στο γράφημα. Τα embeddings είναι προαιρετικά και χρησιμοποιούνται μόνο ως βοηθητικό μέσο υβριδικής αναζήτησης. Τα benchmarks δείχνουν ότι το CRG φθάνει σε 0.909 σε εργασίες multi‑hop retrieval, ενώ η καθαρή ανάκτηση με ομοιότητα δεν μπορεί να εκτελέσει το δεύτερο βήμα.

Question 9

How is this different from LSP and language servers?

Accepted Answer

Οι language servers και το code‑review‑graph (CRG) δημιουργούν ένα δομικό μοντέλο του κώδικά σας, αλλά βελτιστοποιούν για διαφορετικά πράγματα. Το LSP υποστηρίζεται από έναν πραγματικό compiler frontend, παρέχοντας τύπο‑συνειδητά, σημασιολογικά ακριβή αποτελέσματα όπως ακριβές go‑to‑definition, find‑references, live diagnostics, completions και ασφαλείς μετονομασίες. Το CRG χρησιμοποιεί ένα ενιαίο μόνιμο γράφημα αποθηκευμένο σε SQLite, κάνει parsing μία φορά με Tree‑sitter, και υποστηρίζει περίπου 35 γλώσσες καθώς και notebooks από μία διαδικασία. Παρέχει διαγλωσσικές ακμές, σταδιακές ενημερώσεις και ακμές προσανατολισμένες στην ανασκόπηση όπως tests‑for, ροές εκτέλεσης και ανάλυση αλλαγών με βαθμολογία κινδύνου που το LSP δεν μοντελοποιεί.

Επισκόπηση

Βασικές λειτουργίες

Τιμές

Περιπτώσεις χρήσης

Ανασκόπηση Κώδικα

Αξιολόγηση Κινδύνου

Υπέρ και κατά

Υπέρ

Κατά

Κριτικές

Ερωτήσεις

Κάνε μια ερώτηση

Εναλλακτικές για Δεξιότητες