> One idea I’m particularly excited about: rebase doesn’t have to destroy history.
I guess I don't understand why not just merge at that point? The point of rebadge is to destroy history...
The future of version control
251–260 of 407 posts
Re: The future of version control
#252> the key insight is that changes should be flagged as conflicting when they touch each other
Not really. Changes should be flagged as conflicting when they conflict semantically, not when they touch the same lines. A rename of a variable shouldn't conflict with a refactor that touches the same lines, and a change that renames a function should conflict with a change that uses the function's old name in a new place. I don't think I would bother switching to a new VCS that didn't provide some kind of semantic understanding like this.
Re: The future of version control
#253[flagged]
Re: The future of version control
#254[flagged]
Re: The future of version control
#255Guys, there’s a tool called mergiraf[1] that does wonders. I don’t remember my last rebase [1]: https://mergiraf.org/
Yeah, I also thought that a semantic merge is the best solution. It would be nice if it could be extended with custom formats such as sqlite.
Re: The future of version control
#256What CRDT's solve is conflicts at the system level. Not at the semantic level. 2 or more engineers setting a var to a different value cannot be handled by a CRDT. Engineer A intended value = 1 Engineer B intended value = 2 CRDT picks 2 The outcome could be semantically wrong. It doesn't reflect the intent. I think the primary issue with git and every other version control is the terrible names for everything. pull, p…
Yeah, same thoughts. I also think semantic merge is the best. Also it would be nice if you could add a plugin for custom binary file formats, such as sqlite (which obviously can't be merged like a text file).
Re: The future of version control
#257I think something like this needs to be born out of analysis of gradations of scales of teams using version control systems. - What kind of problems do 1 person, 10 person, 100 person, 1k (etc) teams really run into with managing merge conflicts? - What do teams of 1, 10, 100, 1k, etc care the most about? - How does the modern "agent explosion" potentially affect this? For example, my experience working in the 1-100…
> How does the modern "agent explosion" potentially affect this? This changes everything. Agents don't really care what versioning software is used. They can probably figure out whatever you are using. But they'll likely assume it's something standard (i.e. Git) so the easiest is to not get too adventurous. Also, the reasons to use something else mostly boil down to user friendliness and new merge strategies. However…
>Agents don't really care what versioning software is used
Strongly agree that agents don't care about the VCS as they will figure out whatever you throw at them. And you are right about that the merge conflicts are becoming a solved problem when you can just tell an agent to handle it.
But I think there is a much bigger problem emerging that better merge strategies (CRDT or otherwise) do not even touch: the reasoning is gone.
For example the situation taken from the blog is that one side deletes a function while another adds a logging line inside it. The CRDT will give you a better conflict display showing what each side did. Great. But it still doesn't tell you why the function was deleted. Was it deprecated? Moved? Replaced by something else? The reviewer is still reverse-engineering intent from the diff.
This gets/will get much worse with coding agents as agentic commits are orders of magnitude larger, and the commit message barely summarises what happened. An agent might explore three approaches, hit dead ends, flag something as risky, then settle on a solution. All that context vanishes after the session ends.
You are right about codifying guardrails and skills, and I think that is the more productive direction compared to replacing git. We should augment the workflow around it. I also started from a much more radical place, actually, thinking we need to ditch git entirely for agentic workflows [1]. BUT the more I built with agents, the more I realized the pragmatic first step is just preserving the reasoning trail alongside the code, right there in git[2]. No new VCS needed, and the next agent or human that touches the code has the full "WHY" available.
[1] https://github.com/lcbasu/git4aiagents/commit/3a3b197#diff-b... [2]https://www.git4aiagents.com
Re: The future of version control
#258The key insight in the third sentence? > ... CRDTs for version control, which is long overdue but hasn’t happened yet Pijul happened and it has hundreds - perhaps thousands - of hours of real expert developer's toil put in it. Not that Bram is not one of those, but the post reads like you all know what.
Pijul isn't a CRDT is it? It's theory of patches (i.e. DARCS++) alongside native conflicts.
Re: The future of version control
#259The key insight in the third sentence? > ... CRDTs for version control, which is long overdue but hasn’t happened yet Pijul happened and it has hundreds - perhaps thousands - of hours of real expert developer's toil put in it. Not that Bram is not one of those, but the post reads like you all know what.
I have a weird hobby: about once a year I go to the theory page [0] in pijul manual and see if they have fixed the TeX formatting yet. You would think that if a better, more sound model of storing patches is your whole selling point , you would want to make as easy as possible for people who are interested in the project to actually understand it. It is really weird not to care about the first impression that your ma…
Hilarious. I agree that it says a lot how a project handles reports like these.
Re: The future of version control
#260The merge conflict syntax and "doesn't destroy history" both sound exactly like what Fossil does. (Fossil is at https://fossil-scm.org/)
Just a trivial example here:
lorem ipsum
>>>>>> END MERGE CONFLICT >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>