4 ms·

I 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 perso

I 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 regime tells me that, for the most part, the kind of merge conflict being presented here is resolved by assigning subtrees of code to specific teams. For the large part, merge conflicts don't happen, because teams coordinate (in sprints) to make orthogonal changes, and long-running stale branches are discouraged. However, if we start to mix in agents, a 100 person team could quickly jump into a 1000 person team, esp if each person is using subagents making micro commits. It's an interesting idea definitely, but without real-world data, it kind of feels like this is just delivering a solution without a clear problem to assign it to. Like, yes merge-conflicts are a bummer, but they happen infrequently enough that it doesn't break your heart.

CuriouslyC 7mo ago
Team scale doesn't tend to impact this that much, since as teams grow they naturally specialize in parts of the codebase. Shared libs can be hotspots, I've heard horror stories at large orgs about this sort of thing, though usually those shared libs have strong gatekeeping that makes the problem more one of functionality living where it shouldn't to avoid gatekeeping than a shared lib blowing up due to bad change set merges.
tasuki 7mo ago
> 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? Oh god no! That would be about the worst way to do it. Just make it conceptually sound.
- gnarlouse 7mo ago
  Probably, but just introducing CRDTs also feels like the wrong way to approach the problem! :)
- meindnoch 7mo ago
  Also, we need personas! Sally the developer, Mark the UX designer, Taylor the manager. Also, we need to build a community, with the help of evangelists!
jillesvangurp 7mo ago
> 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, lately I just tell codex to pull and deal with merge conflicts. It's not something I have to do manually anymore. That removes a key reason for me to be experimenting with alternative version control systems. It's not that big of a problem anymore. Git was actually designed for massive teams (the Linux kernel) but you have to be a bit disciplined using it in a way that many users in smaller teams just aren't. With agentic coding tools, you can just codify what you want to happen in guardrails and skills. Including how to deal with version control and what process to follow. Where more advanced merge strategies could be helpful is the type of large scale refactoring that are now much easier with agentic coding tools. But doing that in repositories with lots of developers working on other changes is not something that should happen very often. And certainly not without a lot of planning and coordination probably.
- lcbasu 7mo ago
  >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-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5R6-R9 https://github.com/lcbasu/git4aiagents/commit/3a3b197#diff-b... [2]https://www.git4aiagents.com https://www.git4aiagents.com

CuriouslyC 7mo ago

Team scale doesn't tend to impact this that much, since as teams grow they naturally specialize in parts of the codebase. Shared libs can be hotspots, I've heard horror stories at large orgs about this sort of thing, though usually those shared libs have strong gatekeeping that makes the problem more one of functionality living where it shouldn't to avoid gatekeeping than a shared lib blowing up due to bad change set merges.

tasuki 7mo ago

> 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? Oh god no! That would be about the worst way to do it. Just make it conceptually sound.

gnarlouse 7mo ago
Probably, but just introducing CRDTs also feels like the wrong way to approach the problem! :)
meindnoch 7mo ago
Also, we need personas! Sally the developer, Mark the UX designer, Taylor the manager. Also, we need to build a community, with the help of evangelists!

jillesvangurp 7mo ago

> 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, lately I just tell codex to pull and deal with merge conflicts. It's not something I have to do manually anymore. That removes a key reason for me to be experimenting with alternative version control systems. It's not that big of a problem anymore. Git was actually designed for massive teams (the Linux kernel) but you have to be a bit disciplined using it in a way that many users in smaller teams just aren't. With agentic coding tools, you can just codify what you want to happen in guardrails and skills. Including how to deal with version control and what process to follow. Where more advanced merge strategies could be helpful is the type of large scale refactoring that are now much easier with agentic coding tools. But doing that in repositories with lots of developers working on other changes is not something that should happen very often. And certainly not without a lot of planning and coordination probably.

lcbasu 7mo ago
>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-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5R6-R9 https://github.com/lcbasu/git4aiagents/commit/3a3b197#diff-b... [2]https://www.git4aiagents.com https://www.git4aiagents.com