Version control second coming(psantosl.github.io) |
Version control second coming(psantosl.github.io) |
Also, why "second"? Was git the first? But then what about all the other things before it? CVS was huge before, for better or worse.
As a result you have to look at what they share about themselves to infer where they're going with things, because they never explicitly state it. All traits amplified for the worse when people use chat bots too much, in my experience.
Scrolling to the end, they write:
> In 2005 a dozen version control systems fought to replace Bitkeeper, and the winner ended up ruling software development for two decades. Nobody in that race predicted that the decisive factor would be a hosting site with a social network on top.
They had a VCM start-up around their own technology, then Git displaced all other technologies, and then Github ate everyone's lunch. So the first revolution not-so-coincidentally overlaps with the time they ran a SCM startup, and they ignore anything that happened before they entered the space. Funny that.
So the implicit context is the business case and programmer culture around VCM systems.
Meaning the second revolution is anything that challenges Git and Github.
They also keep bringing up gigantic mono-repos and how Git can't handle the scale at which AI increases the amount of code bloat or commits.
So what I read between the lines is that they believe that there are enough people who don't want to actually address the automated hyperscaled Wirth's Law in the room, and are willing to pay services and technology to adapt around it instead.
That's their new business case that will power the second "revolution".
Which sounds horrifying to me, and the worst part is that I can actually see it happening if this AI bubble doesn't pop fast enough.
I don't understand why everyone keeps saying "AI" can write code and somehow the rest of the world can't keep up when we haven't even solved a more basic problem that "AI" itself can't keep up with the code it writes. Claude on the web has to search and scan to find the relevant parts and for whatever reason there is a size limit to how much context I can give to claude and it is laughably low. Shouldn't we be trying to see if it can keep up with itself first? Also not all project files fit in the "context" so once you are in search mode anyway, why is the limit so arbitrarily small? Why not allow at least about 1GiB of plain text? Claude tells me 1 GiB is 250 million tokens and it is too much for current capacity but I thought the whole point of project files was not all of it is in the context window or whatever. It says it is in search mode anyway... So only search for the relevant bit and put only that in the context. You can limit your search to a particular submodule or something but still have broader context where required
I'm not sold on the agentic workflows that AI labs are pushing and haven't yet figured out if/when/how to integrate it into my workflow.
There are two general things I'm weary of with agentic workflows compared to the chat-based workflows:
1. the agentic workflows are much more inclined to go and do the thing rather than involve you in the loop -- e.g. if you are trying to design/plan something;
2. the agents are happy to go and run any command -- you can get them to prompt to confirm the action, but they could easily do something like wipe your home directory, install a random package, or something else.
So, datacenters will fix that.
It was obviously a generalization. The number of AI critics (which eschew AI for coding) are a minority. I would say tiny minority at this point.
Blog authors need a straight up TL;DR because I ain't reading all of that.
I think that's part of why tiktok and yt shorts really took off. It's so short that if you realize it's bad and move on then your wasted investment in terms of time and energy was negligible. (Times 200 that's a different story but signal-to-noise is still high enough that people accept this.)
Banks, airlines, power infra, and other high-stakes customers got computerized in the 60s and 70s. IBM still holds a chunk of that market. Microsoft and Google are not going anywhere. So I guess all that slop will serve something less critical than all of the above.
Great to have an inside view of wrangling technologies for these behemoth data sets.
I use git+lfs for unity projects and it works out great. If I had a real studio I'd buy some perforce seats.
Reinventing the wheel like this is quite exhausting. There are options that are proven to work. AI authorship does not fundamentally violate the idea of some thing owning a specific commit. We don't need new schemas in our source control system. "Provenance" is a bullshit word used to make the AI sound like it's some kind of oracular source with superhuman capabilities.
I don't really see what the article is talking about as the future, but if P4 or Git LFS is the best we can do as a species then we're doomed. All VCS options suck for one reason or another, I hope we don't stop trying to make something better. If only to save me from perforce.
Git is for teams that are distributed across space & time. P4 is significantly better at centralized teams who work in the same physical office.
I am curious what in LFS is breaking for you.
In fact, the way I use Git is hardly any different, I have no interest in getting a black belt in git magic.
What you version together you build and release together, and there are architectural tensions pushing that size down. E.g. dependency indirection and change frequency. Mileage will surely vary by domain, but the idea that the "future is monorepo because agents" doesn't track with me.
The centralisation aspect has less to do with connectedness and more with topology, I'd say. Here, the agentic ways might actually push towards more hierarchical and distributed topologies than the centralised hub-and-spoke.
Will admit it got exactly one thing right, which could absolutely justify everything else (including the price) for a long time: Software Bill of Materials, which is non negotiable in a lot of more serious/heavily regulated development contexts
That still didn't excuse the hacked together pile of ruby scripts our QA lead maintained, each one designed to unfuck a specific weird thing clearcase did. Once everything was on git, they just wrote another script that grabbed a bunch of tags from git and shoved them into clearcase to spit out the bom.
Yet another thing that came from PRIDE, despite that PRIDE itself is little known in today's software industry.
For better or for worse, I don't think Git is going anywhere. A lot of the recent developments in source control amount to providing a better user experience for git repos.
We might well see companies move away from GitHub as source of truth in favor of alternate forges with better SLAs or self-hosting, but dethroning git itself at this point feels very unlikely.
That being said, Git has two big weaknesses: non-text files and handling massive repositories. This is why you see continued use of centralized version control systems (e.g. Perforce, ClearCase) at organizations that need these things. Git LFS tries to address large non-text files, but in my experience teams tend to prefer VCS systems that handle this natively.
At a few big tech companies that decided to use huge monorepos 20 years ago, they've since hand-rolled custom non-git version control systems tailored to their unique scale. These systems usually work by combining a centralized version control server (similar to SVN or Perforce) with a virtual file system that selectively populates code paths based on the current checkout.
But the vast majority of orgs don't need massive monorepos or large amounts of non-text files checked into their repo.
> GitHub has done too many great things over the years, so I hope it remains, but there is obviously an earthquake going on.
Is the 'earthquake' referring to the frequent outages over the last couple of years, and if so are those outages because Microsoft can't keep up with the demand?
It's closer to 'too relevant' than it is to 'no longer relevant'.
Come on at least say "many people". There are plenty of people still coding by hand.
Git is so far good enough for this. It's not particularly user friendly. But that's not a problem for AI agents. What is a problem is that GitHub is a shared resource that is bottle necked on massively increased usage. That's nice if you are sharing code with other people but it becomes a bottleneck otherwise with a clear solution in the form of maybe using faster and compatible (or completely different) alternatives that do things faster/better.
If you sit back and watch what agents do with Git, it involves a lot of agents going through the moves of creating lots of pull requests, waiting for whatever CI systems to kick in, dealing with failures, etc. All that takes a lot of time and tokens and it's designed to compensate for human failures to properly follow processes. So, at least some of that is kind of becoming redundant. With AI we can compensate with more complicated processes instead.
There's definitely some optimization potential lurking there. If you have tens of thousands of agents working on a thing, it might be more efficient to share the burden of integration testing instead of each agent trying to do this independently and testing each micro change in isolation. Also you could question the logic of needing some centralized hub to dump and integrate code. Git is decentralized by design. GitHub is nice as a backup strategy but there are probably cheaper or different ways to do QA and integration with agents. As the development process changes and adapts to all this, the role of Git and Github also needs to be rethought.
As for the rest of the article, it seems a bit too people centric. Virtual file systems are cool. But do AI agents really need them?
The distributed repos and "commit-then-push" metaphor might be due for a replacement since we're always online anyways and repos grow larger and larger. Perhaps using VFS where all files are always instantly available with copy-on-write semantics.
There are several players working on systems that work on thousands of commits per second scale, some based on Git and others not.
Honestly felt like I was missing some sort of satirical masterpiece as the author gleefully declared all the up and coming projects that are going to scatter open source projects to the four corners of the Earth.
Maybe they’ve been so locked into version control tooling as a career they’ve missed the bigger picture, but version control before git ubiquity sucked. Not saying Git is perfect but come on, are our memories so short?
Well - Microsoft worsened GitHub in the last few months with regards to reliability. The next corporate slayer move is to worsen it feature wise. GitHub will indeed most likely remain strong, but the outer shell has some cracks and that means people will be more eager to look for alternatives. It is also a problem that Microsoft has a say in open source projects via GitHub - I never liked that, and many others did not like that either, even more so with Trump acting in a political and ideological manner with his TechBros (who all have nothing to do with Epstein ... right? because what if some of them do ...).
Beyond that, git has a great deal of shortcomings, some obvious, some subtle. It was a regression against SVN in some ways and inferior to Mercurial in others. But the strengths of SCN and Mercurial are again vastly different. There is a reason SVN isn't dead.
My biggest gripe with the open source VCSes is that in the last 20 years, no meaningful evolution happened in the established tools, especially around any weaknesses. Commercial systems like Plastic and Perforce as well as proprietary solutions like piper/jujutsu and sapling show that the tools can still improve drastically. I'm excited for a future where we get better open tools for the masses.
Oh, want to use that other machine as a gateway? Just mount its /net.
Oh, want to route audio through another machine? Just mount their soundcard into your /dev.
Oh, your machine is too puny to do the task at hand? Just run “cpu thebigmachine” which transplanted your entire environment over there (all the virtual file systems) so that you can continue doing what you were doing, but using that machine’s CPU and memory.
This solved the problem of having to transplant your setup to the remote machine, which you have with modern SSH. If you wanted a different environment you instead created it locally. Each process har its own virtual file tree with mounts.
There were cool things at the local level too: All the programs would expose virtual file systems to interact with. Text editor? Each window had a directory with files containing window content, current selection, even the UI “tagline” with commands. This meant you could write scripts for your programs in any language, because you just had to interact with files.
A modern take on plan 9 is definitely on my Christmas wishlist!
Objective-Smalltalk basically provides the sorts of things you write about locally at the language level. You could also move specific instances behind an operating system boundary.
[2] https://dl.acm.org/doi/10.1145/3689492.3690052
[3] https://dl.acm.org/doi/10.1145/2508168.2508169
[4] https://2019.splashcon.org/details/splash-2019-Onward-papers...
Especially the CPU functionality is really interesting. I'm pondering similar problems and the current solutions just aren't good enough.
Please universe I beg you.
Git is incredibly mediocre. But it's all most people know. It's a version control tool that can't handle binary files; and no GitLFS does not count. The end result is a version control tool that is unable to actually version control all the things you need for a project.
This results in a Meta VCS layer where a ton of critical assets are stored in Docker files and other misery. If you want to re-compile a project for 2015 then good luck and god speed.
Personally I think full toolchains belong in source control. And that you should be able to clone / materialize a repro, yank your network cable, and build. This is how big tech monorepos work. It is TheWay imho.
Consider a Linux desktop distro: if every little binary (out of order of magnitude 1000) acted like the center of the universe with gigabytes of build environment and "opinions" galore instead of portability, builds would take much more resources than they already do and parts wouldn't necessarily work together.
There is a good reason why traditionally filesystem access was mediated by the OS layer, but there are many use cases where you just want to give processes a different view of what they already can access and it could be done as a library in the same userspace process.
However, for that to work across all the processes in a session we'd need a standard way to install such a hook in all peocesses and that's achievable to some extent using LD preload but falls apart quite rapidly with statically built binaries or different libcs
In Objective-Smalltalk[1], I can access a file as follows:
hello ← file:hello-world.txt
hello ← https://example.com/hello-world.txt
hello ← env:GREETING
hello ← var:greeting // hello defaults to var:hello
And you can also introduce shortcuts
scheme:greeter ← ref:https://example.com/ asScheme.
hello ← greeter:hello-world.txt
scheme:greeter ← ref:file:./ asScheme
hello ← greeter:hello-world.txt
scheme:greeter ← ref:https://example.com/ asScheme.
scheme:greeter ← #MPWRelativeScheme{ base: 'https://example/com' } → #MPWURLSchemeResolver{}
scheme:img ← #MPWImageDecoderStore{} → scheme:greeter
helloPic ← img:wave.png
While you're right about the disadvantages of git, pretending that it became ubiquitous because it "became a quasi-religion because Linus made it in a day" is selling short its advantages. If you think about it for even just a little bit, it should be obvious what a simplistic statement that it. Also, git was not the stagnation you make it out to be. Even with its warts, it was a breath of fresh air, not unlike jujutsu is now a breath of fresh air vs git.
I remember working with SVN, and all things considered, git was a vast net improvement. Git took a lot of pain away. It made working with a versioned code base faster and simpler, to the point of enabling much better collaborative software development. There's a reason we got GitHub and not SVNhub. And GitHub was what helped git become so dominant.
Would it have been better if Mercurial had beat out git in the propularity contest? Possibly? There's trade-offs between the two, but Mercurial's easier interface counts for a lot. But if it had won, I'm sure we'd be griping about its shortcomings by now.
So yeah, I'm also happy to see some movement around the ergonomics of version control, but I don't understand the need to disparage the tools that got us where we are. It just seems that you're more bitter than happy, and like you're letting that bitterness cloud your judgment.
Git was an improvement over SVN in some aspects, but a monumental regression in others. There are no two ways around that.
Mercurial is better than git in a bunch of ways. It is much more usable because it has way fewer footguns. But it has some of the same shortcomings as git when compared to SVN. I won't call it perfect.
The reason we didn't get svnhub is that some git fanboy nabbed the domain and essentially said "you shall not have it". Joking aside, there was Sourceforge with working SVN support. But I would say that Sourceforge lost market share for a lot of reasons, not all of them technical. Wrapping Windows downloads in adware installers was only one of those many crazy unforced errors.
Am I bitter? Maybe, because I have to use tools that could be so much better. I've experienced better and every time I am forced back to git, it feels a bit painful because I know what we could have instead. If am bitter, it is because of my experience with a wide range of tools.
I also doubt very much that the average monorepo is bigger than the linux kernel. While the latter is a single software as things go, it contains quasi independent subsystems. And those repos don't usually have a merge flow that is as smooth as the Linux kernel. If you have chaotic process, then the result won't be very good and it's not git's fault.
True, but for the problems that Git LFS solves P4 is usually the other option. P4 handles large binaries very well, caveat being the rest of P4. In some projects the caveats are worth it. I work in video games and our in house engine has an unfiltered checkout size over a 1TB.
I've found LFS very brittle when bouncing between branches and moving around in history. There's been many times I've had my local check out blow up through rebases or mistakes I've made. Many times the recovery is to nuke and re-clone. With a 1TB repo that's not a good option.
It's been a while since I've used it, and I'm sure some of my problems were skill issues, but I never found it worth the pain at any scale I've tried to use it.
It's not impossible, there just isn't that much demand for it.
Putting toolchains in perforce is how it works for lots of C++ shops, the setup instructions are “sync and hit build”, whether there’s a toolchain upgrade required or not
For the next time, instead of scrolling, you can just press the little "-" next to a post which collapses it and its whole subtree. Out of sight.
Besides, I explicitly stated that I read 2/3 of the article. How is that "low attention span"? And I didn't just bash it, I formulated what I find missing in it. Do you have answers to those questions? And how does asking such questions indicate "reading difficulties"?
It's quite fascinating that if my comment is so appaling to you, why you'd take the time to respond. I thank you for that though.
Part of the appeal of the Plan 9 approach was that you could use any program in your distributed environment, written in any language, because the abstraction layer was the file system – the lingua Franca of IO.
To start:
An operating system is a collection of things that don’t fit into a language. There shouldn’t be one.
— Dan Ingalls, https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk....
Let's start with an example, the Objective-Smalltalk equivalent of Python's simple web-server for a directory.
Python:
python3 -m http.server 8000
./simplefileserver.st ./ 8000
#!env st
#-server: <ref>dir port: <int>port
framework:ObjectiveHttpd load.
dir asScheme waitOnPort: port.
Here are some other example of what a "ref" can be:
./simplefileserver.st https://objective.st 8000
./simplefileserver.st sftp://otherhost.local 8000
./simplefileserver.st env: 8000
./simplefileserver.st defaults: 8000
./simplefileserver.st class: 8000
./simplefileserver.st scheme: 8000
"Ref" is anything referencable by a polymorphic identifier, a slightly adapted version of a URI. And any ref can be turned into a store (aka "scheme-handler"). And a store can be literally anything that can store and retrieve data by key/index/name/path, from local variables via filesystems, databases all the way to the World Wide Web.
So you can see that you can get the same location transparency that Plan 9 gives you without requiring operating system support. Which comes in handy when you can't switch to a new operating system. What's more, the support extends to a lot of things even Plan 9 probably wouldn't consider a filesystem (local variables?). Last not least, this does not require accessing everything via POSIX API and a byte-serialized representation. Definitely not "least"!
You can access via a byte-serialized representation (as via the http server above) if you want, and you can even access via POSIX API (there is a generic fileserver that serves any of these stores / scheme handlers) if you really, really want. I am not at all sure why you would want that.
And you can, of course, also access this via any language that can talk to C as the libraries that implement the functionality are written in portable Objective-C. Objective-Smalltalk just provides the proper linguistic support.
As a point in case, it's certainly interesting to see you completely disregard jujutsu because it happens to also work (optionally!) with a proprietary backend, when its most useful feature is that it makes working with git night-and-day better, nothing proprietary required. This thing could be a ray of light for you, but for some curious reason, you seem to go out of your way to ignore it.
I mean, it's definitely possible that you think to this day that SVN was the bee's knees and its demise in favor of git or mercurial made us all poorer, but that's certainly a rare perspective. In that context, I'm also finding it hard to reconcile your initial statement around the calcification in VCS land, and now it sounds like you would have preferred to stick with SVN instead.
I'm sure you can give me a rationale for it all, but I wonder how much of it will be just picking rotten (or declared-rotten) cherries out of an otherwise tasty pile. If you stack up the present against a rosy-tinted version of the past and some inexistent pie-in-the-sky, it's no surprise it comes up wanting; but that's just a way to make yourself unhappy, really.
I feel like you are somehow irritated by what I said. Are you personally invested in this discussion somehow?
You have a point in calling me out on jujutsu. I haven't spent enough time looking into it because I have been busy with lots of other things. And I haven't seen any forge-like tooling around it, which further reduced this in my personal priorities. I also got the impression that jujutsu by itself is less scalable than the proprietary jujutsu/piper combo.
The other VCS that I should look into more is Lore. But again, time has been a limiting factor for the past year or so.
You know the really funny thing? I talked to many people with similar skills and experiences as mine and we all essentially have very similar issues with the established open source VCSes.
I had a list of missing features here and it's long and it's boring and I deleted it because it's the kind of stuff that tedious to litigate and what's the point? I'm not here to make anyone switch to something else. I really just hope that we can move past git-as-default into a better era. That's all.
I didn't consider, after my own experience switching from the time of CVS and then SVN to git, with the substantial liberation of workflow that it brought, that somebody would not have that experience, but maybe even an opposite one instead. To be honest, I still find that hard to imagine. That's silly of me, but here we are. I apologize.
(Edit: I do want to add that I also reacted to the hyperbole in your previous comments in this thread, which honestly did not help your opinion to come across as particularly well-considered, so that colored my impression of your position and my response to it.)
> I really just hope that we can move past git-as-default into a better era. That's all.
Than I can only recommend to give jujutsu a try, with its git backend, as sacrilegious as it might sound to you. It offers a much saner and more consistent approach to version control, and with with its abstraction over different possible backends, it offers a way out without having to overcome the considerable problem of having to replace git _first_. A better backed can come later.
Depending on what exactly your issues with git are, you might like it, and it could allow you to have a small part in moving past git right now.
I'm usually not one to fall for, or advocate for new-ish tooling, but jj is one of the few that convinced me. I started using it exclusively with existing git repos; colleagues are still using git with the same repos and are none the wiser. I haven't looked back.
But that depends on your list of missing features, I suppose. If they don't match, I'd be curious what they are and why they might not have been picked up.
It also won't work for version control databases, assuming use of a distributed VCS.
I don’t know what you mean by “ won't work for version control databases, assuming use of a distributed VCS.”