Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Weave – A language aware merge algorithm based on entities

github.com

Post reply on HN
Print view View original

81–90 of 123 posts

Re: Weave – A language aware merge algorithm based on entities

#81

Post by Palanikannan »

evrimoztamur wrote: post #77
rs545837 wrote: post #13

Earlier quoted context omitted.

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 stor…

I would love it if sem was hooked up into a PR review UI...

You mean, something like this?

https://ataraxy-labs.github.io/quiver/

https://x.com/Palanikannan_M/status/2022190215021126004

Re: Weave – A language aware merge algorithm based on entities

#82

Post by rs545837 »

orbisvicis wrote: post #79

It's still possible for two commits to conflict only semantically, one obsoleting the other. Merging both would lead to dead code so perhaps stricter (line-base or ast-based) conflicts would be preferable.

You're right, that's a real risk, weave runs post-merge validation for exactly this, it checks entity dependencies after merge, so if one side obsoletes what the other side depends on, it warns you even when the textual merge is clean

Re: Weave – A language aware merge algorithm based on entities

#86

Post by rs545837 »

orbisvicis wrote: post #80
gritzko wrote: post #12

At this point, the question is: why keep files as blobs in the first place. If a revision control system stores AST trees instead, all the work is AST-level. One can run SQL-level queries then to see what is changing where. Like - do any concurrent branches touch this function? - what new uses did this function accrete recently? - did we create any actual merge conflicts? Almost LSP-level querying, involving versions…

That's a really good point. I'm not familiar with Unison, but I think that's the idea behind the language? https://www.unison-lang.org/

This is actually cool, gonna check it out.

Re: Weave – A language aware merge algorithm based on entities

#87

Post by yvdriess »

rs545837 wrote: post #13
gritzko wrote: post #12

At this point, the question is: why keep files as blobs in the first place. If a revision control system stores AST trees instead, all the work is AST-level. One can run SQL-level queries then to see what is changing where. Like - do any concurrent branches touch this function? - what new uses did this function accrete recently? - did we create any actual merge conflicts? Almost LSP-level querying, involving versions…

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 stor…

Everything that was old will become new again. Content/structural version control used to be a research field. Pharo still uses one afaik https://scg.unibe.ch/archive/papers/Nier13bMonticello.pdf

Re: Weave – A language aware merge algorithm based on entities

#88

Post by zokier »

gritzko wrote: post #12

At this point, the question is: why keep files as blobs in the first place. If a revision control system stores AST trees instead, all the work is AST-level. One can run SQL-level queries then to see what is changing where. Like - do any concurrent branches touch this function? - what new uses did this function accrete recently? - did we create any actual merge conflicts? Almost LSP-level querying, involving versions…

> At this point, the question is: why keep files as blobs in the first place. If a revision control system stores AST trees instead, all the work is AST-level.

The problem is that disks (and storage in general) store only bytes so you inherently need to deal with bytes at some point. You could view source code files as the serialization of the AST (or other parse tree).

This is especially apparent with LISPs and their sexprs, but equally applies to other languages too.

Re: Weave – A language aware merge algorithm based on entities

#89

Post by pfdietz »

rs545837 wrote: post #42
pfdietz wrote: post #35

Earlier quoted context omitted.

Well, if you're programming in C or C++, there may not be a parse tree. Tree-sitter makes a best effort attempt to parse but it can't in general due to the preprocessor.

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 appr…

It's an argument against preprocessors for programming languages.

Tree-sitter's error handling is constrained by its intended use in editors, so incrementality and efficiency are important. For diffing/merging, a more elaborate parsing algorithm might be better, for example one that uses an Earley/CYK-like algorithm but attempts to minimize some error term (which a dynamic programming algorithm could be naturally extended to.)

Re: Weave – A language aware merge algorithm based on entities

#90

Post by [deleted] »

rs545837 wrote: post #6

Some context on the validation so far: Elijah Newren, who wrote git's merge-ort (the default merge strategy), reviewed weave and said language-aware content merging is the right approach, that he's been asked about it enough times to be certain there's demand, and that our fallback-to-line-level strategy for unsupported languages is "a very reasonable way to tackle the problem." Taylor Blau from the Git team said he'…

[deleted]
Post reply on HN