51–60 of 123 posts
[flagged]
>I feel git is done for good I'm either not understanding your comment or not understanding the project. Isn't this built on top of git?
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.
Earlier quoted context omitted.
https://github.com/Ataraxy-Labs/weave/pull/11 Dude did you just call me AI generated haha, i've been actively using weave for a gui I've been building for blazingly fast diffs https://x.com/Palanikannan_M/status/2022190215021126004 So whenever I run into bugs I patched locally in my clone, I try to let the clanker raise a pr upstream, insane how easy things are now.
[flagged]
[flagged]
You made a pull request not from your own fork, but from a separate branch, https://github.com/Ataraxy-Labs/weave/pull/9
[flagged]
You have write access to this git repo as a first time contributor. You are likely the owner of this repo as well. You made a pull request not from your own fork, but from a separate branch, https://github.com/Ataraxy-Labs/weave/pull/9
[flagged]
You have write access to this git repo as a first time contributor. You are likely the owner of this repo as well. You made a pull request not from your own fork, but from a separate branch, https://github.com/Ataraxy-Labs/weave/pull/9
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…
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.
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 mergigraf
Earlier quoted context omitted.
You have write access to this git repo as a first time contributor. You are likely the owner of this repo as well. You made a pull request not from your own fork, but from a separate branch, https://github.com/Ataraxy-Labs/weave/pull/9
He also was pushing code to a branch on the same repo three weeks ago: https://github.com/Ataraxy-Labs/weave/commits/fix/utf8-panic... but is acting in this post like he just discovered the project.
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