sem

I posted about my project below - https://github.com/0x007BA7/codebook But maybe you should checkout the tools it’s based on, sem - https://github.com/Ataraxy-Labs/sem and ultimately treesitter. They at least give a more structured approach to dealing with code than simple text.

jj is genuinely great and I think it deserves way more adoption than it has right now. The mental model is so much cleaner than git, undo actually works the way you'd expect it to, and working with stacked changes feels natural instead of that constant low-grade anxiety of actually breaking something. It's probably the best frontend for version control that exists today. For the last few months though I've been thinking a lot about what you said at the end there. What if version control actually understood the code it was tracking, not as lines of text but as the actual structures we write and think in, functions, classes, methods, the real building blocks? A rename happening on one branch and an unrelated function addition on another aren't a real conflict in any meaningful sense, they only look like one because every tool we have today

Really fun work, and the writeup on the math is great. The Beta-Bernoulli conjugacy trick making the marginal likelihood closed-form is elegant. We ran benchmarks comparing bisect vs bayesect across flakiness levels. At 90/10, bisect drops to ~44% accuracy while bayesect holds at ~96%. At 70/30 it's 9% vs 67%. The entropy-minimization selection is key here since naive median splitting converges much slower. One thing we found, you can squeeze out another 10-15% accuracy by weighting the prior with code structure. Commits that change highly-connected functions (many transitive dependents in the call graph) are more likely culprits than commits touching isolated code. That prior is free, zero test runs needed. Information-theoretically, the structural prior gives you I_prior bits before running any test, reducing the total tests needed from

usually the whole discussion has been around line-level vs commit-level history, but there's a layer nobody's talking about, and I have been exploring it here these days with https://github.com/Ataraxy-Labs/sem. It gives you entity-level version control. It parses your code into functions, classes, methods using tree-sitter (12 languages so far), computes a structural hash for each entity, and builds a cross-file dependency graph. So sem diff HEAD~1 doesn't give you "+3 -2 in tax.py", it gives you "calculate_tax signature changed, 47 dependents, 3 callers will break". The key insight is distinguishing signature changes from body changes.

We've been building an open source tool called sem (https://github.com/ataraxy-labs/sem) that takes this one level further: entity-level diffs instead of AST-level. Instead of showing you which syntax nodes changed, it shows you which functions, classes, and methods changed, classifies the change (text-only, syntax, functional), and walks a dependency graph to tell you the blast radius. The delta + difftastic integration problem in that issue is interesting because sem already has the pieces both sides need, before/after content with full context for every changed entity, plus structured JSON output. The blocker in #535 is that difftastic's JSON doesn't include surrounding context. sem's output includes complete entity bodies by default. Would love to collaborate on a common interchange format if anyone from the delta or difftastic projec

Looks similar to sem/weave https://github.com/ataraxy-labs/sem https://github.com/ataraxy-labs/weave Though, despite the claims, I am not sure if these are ready for prime-time yet. I have noticed some rather concerning merge "resolutions".

https://github.com/Ataraxy-Labs/sem stores AST operations in git https://news.ycombinator.com/item?id=47294924

Git line diffs are 40 years old. they still can't tell the difference between "renamed a variable" and "rewrote the logic." your diff tool doesn't understand your code, it never did. we fixed that, introducing Semantic diffs! Fully deterministic, no llm calls Powered by https://github.com/ataraxy-labs/sem

Great point. C/C++ with macros and preprocessor directives is where tree-sitter's error recovery gets stretched. We support both C and C++ in sem-core(https://github.com/Ataraxy-Labs/sem) but the entity extraction is best-effort for heavily macro'd code. For most application-level C++ it works well, but something like the Linux kernel would be rough. Honestly that's an argument for gritzko's AST-native storage approach where the parser can be more tightly integrated.

We got asked this on the X thread too, when we went viral here https://x.com/rs545837/status/2021020365376671820. Your git doesn't change at all. Weave plugs in through git's merge driver interface (.gitattributes), so git still handles everything, it just calls weave for the content merge step instead of its default line-level algorithm. All your git commands, workflow, and history stay exactly the same. For diffing arbitrary files outside git, we built sem (https://github.com/ataraxy-labs/sem) which does entity-level diffs. sem diff file1.py file2.py shows you which functions changed, were added, or deleted rather than line-level changes

This is the right question. Storing ASTs directly would make all of this native instead of layered on top. The pragmatic reason weave works at the git layer: adoption. Getting people to switch merge drivers is hard enough, getting them to switch VCS is nearly impossible. So weave parses the three file versions on the fly during merge, extracts entities, resolves per-entity, and writes back a normal file that git stores as a blob. You get entity-level merging without anyone changing their workflow. But you're pointing at the ceiling of that approach. A VCS that stores ASTs natively could answer "did any concurrent branches touch this function?" as a query, not as a computation. That's a fundamentally different capability. Beagle looks interesting, will dig into the BASON format. We built something adjacent with sem (https://github.com/atar

Git diffs are great for humans scanning line noise. But agents need to understand changes: "added function X", "renamed symbol Y", "moved block Z". sem computes semantic diffs on top of your Git repo—no repo rewrite needed. Repo: https://github.com/Ataraxy-Labs/sem Key ideas: Parses code to AST, computes tree‑edit ops (add/remove/move/change). Outputs human‑/agent‑readable patches: "diff_sem" shows intent, not whitespace churn. Applies deterministically via git apply --sem—survives formatting shifts or unrelated edits. Use cases popping up: Agent codemods: output semantic patches instead of brittle hunks. Review tools: "explain this PR as semantic changes". Stacked diffs / Graphite: semantic base for stacks. Bulk refactors: apply "rename all X to Y" across noisy repos.

We ran 24 API calls through Claude Sonnet 4.6 - same questions about code changes, same model, same temperature. One gets git diff output. The other gets structured JSON from sem diff. Results: 95.9% accuracy vs 41.5%. The failure modes are systematic, not random: 1. git diff has no concept of "entity." Ask an agent to count added functions and it counts + lines instead. On one commit it reported 238 adds - that was the number of + lines. Actual: 32 entities. 2. No way to distinguish add vs modify. A modified function shows +/- hunks, same as a new function in a changed file. The model listed 9 "added" functions - 4 were actually modified. Precision: 55.6%. 3. No entity type vocabulary. Asked for entity type counts, the model returned {"file": 11}. It counted files because line diffs have no AST. Truth: 15 functions, 12 interfaces, 3 vari