> The old model assumed one person, one branch, one terminal, one linear flow. Not only has the problem not been solved well for that old model, it’s now only been compounded with our new AI tools.
A bit of a strange thing to say in my book. Git isn't SVN and I think these problems are already solved with git. I agree that the interface is not always very intuitive but Git has the infrastructure which is very much focused on supporting alternatives to "one person, one branch, one terminal, one linear flow".
> the problem that Git has solved for the last 20 years is overdue for a redesign.
To me it's not clear what the problem is that would require a redesign.
> To me it's not clear what the problem is that would require a redesign.
The interface is still bad. Teaching people to use git is still obnoxious because it's arcane. It's like 1e AD&D. It does everything it might need to, but it feels like every aspect of it is bespoke.
It's also relatively difficult to make certain corrections. Did you ever accidentally commit something that contains a secret that can't be in the repository? Well, you might want to throw that entire repository away and restore it from a backup before the offending commit because it's so difficult to fix and guarantee that it's not hiding in there somewhere and while also not breaking something else.
It's also taken over 10 years to address the SHA-1 limitation, and it's still not complete. It's a little astonishing that it was written so focused on SHA-1 never being a problem that it's taken this long to keep the same basic design and just allow a different hashing algorithm.
More power to them for re-visiting this, but agree with you:
> The old model assumed one person, one branch, one terminal, one linear flow.
That sounds exactly like the pre-git model that git solved..
I've always wanted a kind of broader and more integrated approach that isn't just about text diffs. the ability to link in substantial comments that would be displayed optionally and not piss off linear readers. links to design and reference documents. bugs and prs that were persistent and linked to the versioned code instead of being ephemeral.
think about all of the discussion we have around the code that gets lost. we certainly have the ability to keep and link all that stuff now. we don't really need to have arguments about squashing or not, we can just keep the fine grained commits if you really want to dig into them and maybe ask that people write a comprehensive summary of the changes in a patch set -in addition-.
but I guess none of that has anythig to do with AI
[dead]
The problem is how to make money from something that is more or less solved.