I watched the video and I don't really understand how this maps to the underlying Git operations and what it can do. What happens if I make changes locally while Cursor is doing something? Is this detected properly? (That might be useful.) Can I use it with Claude Code too in some way? Is it primarily for syncing with external tools like Lovable?
Also, the ChatGPT generated copy for the landing page is somewhat off-putting.
My idea is that we should not commit LLM written code, but rather we should commit the prompts. The LLM prompts are source code, the LLM code is target code. If you use typescript and scss, you would commit that, not the generated js and css.
That LLMs are typically non-deterministic introduces some issue, but surely you can achieve determinism with seeds, specific model revisions and 0 temperature.
Your example shows everything that is wrong with SWE nowadays. Can you right now generate anything without an internet connection? I guess not. Also what the fuck can I do with that repository? There is no code, nothing useful to me, no automated way to build the application, and the source code can change every time you generate it which means no specifications, no tests, no way to improve this application, and no way to create regression tests. If I ever saw that thing at work, it would go to the trash can.
Baffling. Not at all clear from the site or video what this does, what problem it is solving, and what about LLM coding is different such that it needs new ideas in version control. Is it just that there are more commits and more conflicts because people are pushing more garbage without regard for consistency and stability? I would suggest solving that by pushing less garbage, or at least having fewer people pushing garbage to the same place at the same time.
How does it resolve conflicts? If you want to resolve conflicts automatically, try the excellent Mergiraf, which works by looking at the AST rather than the line-by-line diff: https://mergiraf.org/
Branching continuously synchronises your Git repository with GitHub and automatically resolves conflicts on rebase - removing manual pull/push, management of branches, and conflict resolution. The exact merge strategy is evolving - we are starting with deterministic "take incoming" and testing structural and AI-assisted options. The guiding principle: automate the routine merges, leave full control in developer's hands when it matters.
You are right that some situations do require careful inspection of changes to avoid "garbage". In others cases you might not care about internals if behaviour looks correct, e.g. for a prototype.
Our "progressive depth" approach in Branching aims to serve both cases - default automatic behaviour, and the option to do Git operations manually when you need to - including editing conflicts manually or with tools like Mergiraf. That way the busy path stays fast, and the careful path is still just plain Git.
We need new version control workflows or just a usability layer on top of git with the Proliferation of agentic coding. But this is not it - jm not sure what ita actually doing and its opaque.
10 comments
[ 7.9 ms ] story [ 27.7 ms ] threadAlso, the ChatGPT generated copy for the landing page is somewhat off-putting.
Version control isn’t specific to A.I workflows, what does this add on top of git?
Is this a worktree type solution so you could make parallel edits?
https://github.com/TZubiri/keyboard-transpositions-checker
My idea is that we should not commit LLM written code, but rather we should commit the prompts. The LLM prompts are source code, the LLM code is target code. If you use typescript and scss, you would commit that, not the generated js and css.
That LLMs are typically non-deterministic introduces some issue, but surely you can achieve determinism with seeds, specific model revisions and 0 temperature.
How does it resolve conflicts? If you want to resolve conflicts automatically, try the excellent Mergiraf, which works by looking at the AST rather than the line-by-line diff: https://mergiraf.org/
You are right that some situations do require careful inspection of changes to avoid "garbage". In others cases you might not care about internals if behaviour looks correct, e.g. for a prototype.
Our "progressive depth" approach in Branching aims to serve both cases - default automatic behaviour, and the option to do Git operations manually when you need to - including editing conflicts manually or with tools like Mergiraf. That way the busy path stays fast, and the careful path is still just plain Git.
I’m just gonna keep typing ‘hg commit’ and plow ahead.