rs545837

7 ms·

1. 61.▲
   by rs545837 7mo ago

   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.
2. 62.▲
   by rs545837 7mo ago

   Really appreciate the detail here, this is clearly hard-won experience. I agree that indentation is structural in Python.
3. 63.▲
   by rs545837 7mo ago

   what kind of compariosn table are you looking for? I actually added that on the website https://ataraxy-labs.github.io/weave/
4. 64.▲
   by rs545837 7mo ago

   Actually tackled it here: https://x.com/rs545837/status/2021423280410988580 Cheers,
5. 65.▲
   by rs545837 7mo ago

   This is exactly a reason why weave stays on top of git instead of replacing storage. Parsing three file versions at merge time is fine (was about 5-67ms). Parsing on every read/write would be a different story. I know about Lix, but wi
6. 66.▲
   by rs545837 7mo ago

   Yup he works at Plane, and he used weave in merge conflicts there which helped him, he just told about it. He has been contributing and using weave since then.
7. 67.▲
   by rs545837 7mo ago

   Yeah he is the other contributor to the repo.
8. 68.▲
   by rs545837 7mo ago

   Nope that's other user, he has been working with me on weave, check the PRs that you are calling AI generated.
9. 69.▲
   by rs545837 7mo ago

   I think he was just being sarcastic, git's so amazing it can never be done for good. Yeah it's just a merge driver that will sit on top of git.
10. 70.▲
    by rs545837 7mo ago

    Of course!
11. 71.▲
    by rs545837 7mo ago

    When you're just a normal guy genuinely trying to build something great and there's nobody who believes in you yet, the only thing you can do is go to projects you admire and ask "would this help you?" Patrick Collison d
12. 72.▲
    by rs545837 7mo ago

    Thanks, lemme know how it goes, I will review and we can discuss over the issue.
13. 73.▲
    by rs545837 7mo ago

    Awesome, let me know how it goes. Happy to help if you hit any rough edges.
14. 74.▲
    by rs545837 7mo ago

    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 extra
15. 75.▲
    by rs545837 7mo ago

    Thanks a lot, I will test it out as you said, in the mean time, could you also open up an issue on the repo, so that it helps me and others to track the issue.
16. 76.▲
    by rs545837 7mo ago

    Haha appreciate the love man! Still early days but the fact that entity-level context cuts tokens that much validates the whole thesis. Glad it's working for you, keep the feedback coming.
17. 77.▲
    by rs545837 7mo ago

    Thanks again for criticising, so tackling each of your comment: GitHub’s ToS, because you suspect, so I can help you understand them. > What violates it: 1. Automated Bulk issues/PRs, that we don't own 2. Fake
18. 78.▲
    by rs545837 7mo ago

    Yes, weave detects renames via structural_hash (AST-normalized hash that ignores identifier names). If both sides rename the same function, it matches by structure and merges cleanly.
19. 79.▲
    by rs545837 7mo ago

    Thanks for trying it! Would love to know what the merge conflict looked like, if you can share the repo or a minimal repro, I'll dig into why it didn't resolve. That kind of feedback is exactly what helps us improve.
20. 80.▲
    by rs545837 7mo ago

    Swift isn't supported yet but adding a new language is straightforward since we use tree-sitter. There's already a tree-sitter-swift grammar. Would happily accept a PR for it, if you are down for it.
21. 81.▲
    by rs545837 7mo ago

    What do you mean?
22. 82.▲
    by rs545837 7mo ago

    Thanks a lot for the fair criticism, Appreciate it! You're right that those links aren't the strongest evidence. The real argument isn't "people are complaining on twitter." It's just much simpler when two agen
23. 83.▲
    by rs545837 7mo ago

    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 (.git
24. 84.▲
    by rs545837 7mo ago

    Thanks for commenting, Good question. Python was one of the trickier ones to get right. Tree-sitter parses the full AST including indentation structure, so weave knows that an indented block belongs to its parent class or function. When mer
25. 85.▲
    by rs545837 7mo ago

    So that you don't feel that I am biased about my thing but just giving more context that it's not just me, its actually people saying on twitter how often the merging breaks when you are running production level code and often mer
26. 86.▲
    by rs545837 7mo ago

    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 s
27. 87.▲
    by rs545837 7mo ago

    Hey, author here. This comparison came up a lot when weave went viral on X ( https://x.com/rs545837/status/2021020365376671820 ). The key difference: mergiraf matches individual AST nodes (GumTree + PCS triples). We
28. 88.▲
    by rs545837 7mo ago

    Haha, thanks for the feedback, yeah multi agent workflows were especially kept in mind when designing this! So I hope it helps, I am always here for feedback and feature requests.
29. 89.▲
    by rs545837 7mo ago

    Thanks for the request, our team is already working on it, and infact we were going to ship ruby tonight! Cheers,
30. 90.▲
    by rs545837 7mo ago

    Yes I designed it for agents especially, there's also weave mcp that I built that you can checkout. The good part is that this research extends really good for code review because tracking entities is more semantically rich than lines.