Hacker News new | ask | show | jobs
by dcre 353 days ago
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/

2 comments

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.

I don't know about this product but I think we need to version control the prompts together with the code.
That won't help much unless the LLM model version remains constant, is added, and/or can be invoked again. Not impossible for locally hosted models, but nigh impossible for the ever-changing online ones.
You do! I personally organize them into Markdown playbooks, organized in a way that makes sense for the project, and which live in the repo’s .claude folder (or .ai, or whatever).