101–110 of 123 posts
Earlier quoted context omitted.
Does this actually matter for multi-agent use cases? Surely people that are using swarms of AI agents to write code are just letting them resolve merge conflicts.
I'm running agents doing merges right now, and yes and no. They can resolve merges, but it often takes multiple extra rounds. If you can avoid that more often it will definitely save both time and money.
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'…
Are any of these statements public, or is this all private communication?
> We are also working with GitButler team to integrate it as a research feature.
Referring to this discussion, I assume: https://github.com/gitbutlerapp/gitbutler/discussions/12274
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'…
> 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's "really impressed" and connected us…
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…
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
These things are genuinely not letting me sleep these days.
How can this be used with jj?
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…
You might need a bit more than ASTs, as you need code to be human-readable as well as machine-readable. Maybe CSTs?
Earlier quoted context omitted.
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/
worth mentioning that mergiraf is already supported for windows. from https://github.com/Ataraxy-Labs/weave/issues/7 it looks like it's planned for weave too at some point?
Earlier quoted context omitted.
what kind of compariosn table are you looking for? I actually added that on the website https://ataraxy-labs.github.io/weave/
that's pretty cool, thank you worth mentioning that mergiraf is already supported for windows. from https://github.com/Ataraxy-Labs/weave/issues/7 it looks like it's planned for weave too at some point?
Earlier quoted context omitted.
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 li…