Ask HN: What does the next evolution of version control look like?
What is next for version control? What works well about the current systems and what is starting to break with current software development practices?
I've been spending some time studying the history of different parts of my software stack I've used for years but did not know the background of. From my vantage point, it doesn't seem like many things have fundamentally changed about version control since the late-2000s, early 2010s, while many other parts of the dev stack have changed dramatically.
9 comments
[ 3.0 ms ] story [ 39.9 ms ] threadWhat do you think?
But a few things that have always stood out to me about the user experience of version control:
- Git allows us to work in parallel effectively on different branches, but when our whole team is focused on one set of interrelated new features, we spend a lot of overhead coordination time figuring out how to not create conflicts for eachother. So we can work in parallel, but not in real-time with eachother's changes. The multiplayer aspect of design in Figma comes to mind here.
- I and many folks at my level use github in much simpler way than many older coworkers do. I rarely touch anything that isn't basic branching, commits and merging
- As a very visual thinker, it took me a very long time to grok git and what I was doing. As I've worked with more devs who come from non-engineering backgrounds, I've found this pretty common
If multiple people work on the same code (interrelated new features) at the same time, it seems to me they would have to sequence their work (i.e. coordinate) so as to not step on each others' toes. Put differently, this sounds like the problem is inherent and won't be solved by technology.
I know there are issues with open source projects getting a lot of spam PRs from folks trying to fluff their contributions on their profiles. I can definitely see that getting worse with AI systems, but I haven't been in these communities enough to be familiar with that pain myself.
To deal with dependency churn, CVEs etc people have started setting up automatons to generate PRs. Those can generate a ton of them with minimal information about their real impact(unlike human PRs) and so going through them is not only a lot of work but the volume can be much greater. I'm certain people will begin adding LLM based automatons soon too.
Because of that I think the next big deal will be creating a separate class of changesets for machine suggested changes.
That's a super interesting take. The obvious thing is that the surface area of automation has improved and you can build a lot of tools to help with that, but you also need tooling to help deal with that overload of new automation - especially if your bandwidth is limited.
Some of them had huge weaknesses evident from the start - for example CVS had little support for maintaining directory structures. The upside of CVS is that when things got screwed up, which they did often, I could go in and fix up the hidden files, since they were more or less human-readable.
Git seems to have the edge because it is reliable - I've never seen it crash - and because it can do just about anything I've ever wanted to diagram out. It's also very good about being able to roll back mistakes.
My beef with Git is the user interface. It's often still very hard to figure out exactly which command I need and the structure of commands, and their options, are often very non-orthogonal. Using checkout to branch is pretty much the simplest example I can think of. The fact that so many git commands have output that tells you what to do to fix the inevitable problem you're going to run into next is kind of a tell that the functionality is badly structured into commands. I have two "front ends" to Git - TortoiseGit if I'm on Windows, and Stack Overflow if I'm not.
If you've never heard of Voodoo, it was a commercial product for Mac and worked really well, with its concept of "orthogonal version management." I think this concept is still interesting: https://link.springer.com/chapter/10.1007/3-540-60578-9_4 It also had a feature I miss frequently, which is meaningful support for non-text files. Back when I was doing Mac programming I used this a lot.
The other one that I think has things worth studying is darcs. The Haskell source is quite amazing, although it has not really become popular in part because, at least when I last tested it, it was pretty slow. http://darcs.net/
I think Git's ties to GitHub are problematic. I know it's not required to use it with GitHub, there's the GitLab alternative, but it's the infrastructure that's been presented to me at my last few gigs. It has a lot of nice features but it encourages so much ceremony about the most minimal code change that it adds a lot of friction and it's easy to mistake activity for progress.
I definitely agree with your points about UI and the ceremonies of our current version control system.
One thing I've been thinking about this morning is that maybe it isn't the underlying protocol that needs to evolve, but the user experience that sits on top of the protocol. As I've asked this question to many engineers in my network, most are satisfied with the technical performance of git and the problem it solves, and their pains are almost all on the UX and organizational layer.