This sounds good, but I wonder if AI has changed the calculus on conflict resolution. It can not only chase down the conflicting changes, but also read those commit messages and PRs to divine intent. It might be that git is "good enough," given we have AI.
The future of version control
221–230 of 407 posts
Re: The future of version control
#222Does this mean he’s given up on Chia?
Re: The future of version control
#223Earlier quoted context omitted.
After 15 years i still cant remember which is which. I get annoyed every time. Maybe I should invest 15 minutes finally to remember properly
Let’s see if I get this wrong after 25 years of git: ours means what is in my local codebase. theirs means what is being merged into my local codebase. I find it best to avoid merge conflicts than to try to resolve them. Strategies that keep branches short lived and frequently merging main into them helps a lot.
> Let’s see if I get this wrong after 25 years of git
You used it 5 years before Linus? Impressive!
Re: The future of version control
#224Thank you. This sounds like a great approach! I’ve also been surprised at the mechanical nature that git resolves conflicts in, and the loss of intent when auto-merging.
Re: The future of version control
#225Earlier quoted context omitted.
"Ours" and "theirs" make sense in most cases (since "ours" refers to the HEAD you're merging into). Rebases are the sole exception (in typical use) because ours/theirs is reversed, since you're merging HEAD into the other branch. Personally, I prefer merge commits over rebases if possible; they make PRs harder for others to review by breaking the "see changes since last review" feature. Git generally works better wit…
> Git generally works better without rebases and squash commits. If squash commits make Git harder for you, that's a tell that your branches are trying to do too many things before merging back into main.
I don't know. Even when I'm working on my own private repositories across several machines, I really, really dislike regular merges. You get an ugly commit message and I can never get git log to show me the information I actually want to see.
For me, rebasing is the simplest and easiest to understand, and it allows you to squash some of your commits so that it's one commit per feature / bug-fix / logical unit of work. I'll also frequently rebase and squash commits in my work branch too, where I've temporarily committed something and then fixed a bug before it's been pushed into main, I'll just reorder and squash the relevant commits into one.
Re: The future of version control
#226I'm struggling to understand the problem this solves for me. I can see in the abstract why this might be useful, but in practice I don't see the problems. For me, jj represents a massive step forward from git in terms of usability, usefulness, and solving problems I actually have. I think the next step forward for version control would be something that works at a lower level, such as the AST. I'd love to see an expl…
It is coming. Had to build a whole new system of parsers.
Re: The future of version control
#227Has anyone considered a VCS that integrates more vertically with the source code through ASTs? IE if I change something in my data model, that change & context could be surfaced with agentic tooling.
That's me, with BABLR. Working on getting a beta release announced in the next few days.
Re: The future of version control
#228Earlier quoted context omitted.
> You can't use CRDTs for version control You misunderstand what is being proposed. Using CRDTs to calculate the results of a merge does not require being allowed to commit the results of that calculation, and doesn't even require that you be able to physically realize the results in the files in your working copy. . Consider for example if you want to track and merge scalar values. Maybe file names if you track rena…
If semantics-layer conflicts still have to be detected somehow, and resolved by hand, what value is the underlying CRDT providing?
> the result is always the same no matter what order branches are merged in — including many branches mashed together by multiple people working independently.
Re: The future of version control
#229Earlier quoted context omitted.
If semantics-layer conflicts still have to be detected somehow, and resolved by hand, what value is the underlying CRDT providing?
> the result is always the same no matter what order branches are merged in — including many branches mashed together by multiple people working independently.
Why is that valuable?
Re: The future of version control
#230Bram Cohen is awesome, but this feels a little bare. I've put much more thought into version control ([1]), including the use of CRDTs (search for "# History Model" and read through the "Implementing CRDTs" section). [1]: https://gavinhoward.com/uploads/designs/yore.md
Is this the Bram Cohen who made bittorrent? There is surprisingly little information on this page.
Yes, just look at his Github page.