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

61–70 of 123 posts

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

#61

Post by rs545837 »

_flux wrote: post #58

How does it compare to https://mergiraf.org/ ? I've had good experience with it so far, although I rarely even need it. It's also based on treesitter, but probably otherwise a more baseline algorithm. I wonder if that "entity-awareness" actually then brings something to the table in addition to the AST. edit: man, I tried searching this thread for mention of the tool for a few times, but apparently its name is not me…

Actually tackled it here: https://x.com/rs545837/status/2021423280410988580

Cheers,

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

#62

Post by _flux »

rs545837 wrote: post #61
_flux wrote: post #58

How does it compare to https://mergiraf.org/ ? I've had good experience with it so far, although I rarely even need it. It's also based on treesitter, but probably otherwise a more baseline algorithm. I wonder if that "entity-awareness" actually then brings something to the table in addition to the AST. edit: man, I tried searching this thread for mention of the tool for a few times, but apparently its name is not me…

Actually tackled it here: https://x.com/rs545837/status/2021423280410988580 Cheers,

I think it would be interesting to include it in the comparison table, as I think it could be viewed as a base line language-aware merge tool.

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

#63

Post by rs545837 »

_flux wrote: post #62
rs545837 wrote: post #61

Earlier quoted context omitted.

Actually tackled it here: https://x.com/rs545837/status/2021423280410988580 Cheers,

I think it would be interesting to include it in the comparison table, as I think it could be viewed as a base line language-aware merge tool.

what kind of compariosn table are you looking for? I actually added that on the website https://ataraxy-labs.github.io/weave/

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

#64

Post by rs545837 »

hrmtst93837 wrote: post #52
SurvivorForge wrote: post #16

The entity-level approach is a meaningful step up from line-based merging. Anyone who has dealt with a merge conflict where git splits a function signature across conflict markers knows how much context is lost at the line level. Curious how this handles languages with significant whitespace like Python, where indentation changes can shift the semantic meaning of entire blocks.

[flagged]

Really appreciate the detail here, this is clearly hard-won experience. I agree that indentation is structural in Python.

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

#66

Post by gritzko »

samuelstros wrote: post #57
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…

How do you get blob file writes fast? I built lix [0] which stores AST’s instead of blobs. Direct AST writing works for apps that are “ast aware”. And I can confirm, it works great. But, the all software just writes bytes atm. The binary -> parse -> diff is too slow. The parse and diff step need to get out of the hot path. That semi defeats the idea of a VCS that stores ASTs though. [0] https://github.com/opral/lix

I only diff the changed files. Producing blob out of BASON AST is trivial (one scan). Things may get slow for larger files, e.g. tree-sitter C++ parser is 25MB C file, 750KLoC. Takes couple seconds to import it. But it never changes, so no biggie.

There is room for improvement, but that is not a show-stopper so far. I plan round-tripping Linux kernel with full history, must show all the bottlenecks.

P.S. I checked lix. It uses a SQL database. That solves some things, but also creates an impedance mismatch. Must be x10 slow down at least. I use key-value and a custom binary format, so it works nice. Can go one level deeper still, use a custom storage engine, it will be even faster. Git is all custom.

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

#67

Post by kubb »

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

Congrats on getting acknowledged by people with credibility.

I also think that this approach has a lot of potential. Keep up the good work sir.

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

#69

Post by rs545837 »

alkonaut wrote: post #65

> This happens constantly when multiple AI agents work on the same codebase What? Is the idea of "multiple agents" of flesh and blood writing code that far fetched now?

I meant when they each work on a separate branch and merge back, you get the similar kinds of conflicts, where a bunch of them should not even be a conflict, so weave is trying to solve it.

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

#70

Post by tomaskafka »

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…

[flagged]
Post reply on HN