7 ms·

Version control second coming

101 points by bananaboy 25d ago

bolangi 23d ago
Dreaming of "virtual filesystems everywhere". Hmm, sorta sounds like Plan 9. Great to have an inside view of wrangling technologies for these behemoth data sets.
- forrestthewoods 23d ago
  > virtual filesystems everywhere 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.
  - ahartmetz 23d ago
    IMO screw that. It's maybe a good way to build software in exactly one environment for exactly one environment, deployment to a corporate server fleet. 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.
    - forrestthewoods 22d ago
      Deduping files is easy.
      - ahartmetz 22d ago
        It's also useless if every tool lives in its own copy of the universe - there'd be little to no identical files. It also won't work for version control databases, assuming use of a distributed VCS.
        forrestthewoods 22d ago
        Yes it would require a global blob store across reps. That seems like a good design choice. I don’t know what you mean by “ won't work for version control databases, assuming use of a distributed VCS.”
        ahartmetz 21d ago
        The .git directory does not contain plain files, so the same files may look different in different .git directories. But yeah, you could make it work if you designed for it.
        forrestthewoods 21d ago
        Yeah Git is super mediocre. But the hypothesis is that you could build something that doesn’t suck!
  - Kwpolska 23d ago
    Visual Studio and Xcode take up tens of gigabytes, are updated often, and include system components. Storing them in VCS is impossible, and would be a waste of disk space.
    - dist-epoch 23d ago
      You could consider ZFS a VCS, and it can easily store multiple versions (snapshots) of Visual Studio. It's not impossible, there just isn't that much demand for it.
    - maccard 23d ago
      Disagree. They’re stored _somewhwre_ anyway, and they may as well be versioned. 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
    - forrestthewoods 22d ago
      Literally not impossible. And also not tens of gigabytes.
- black_knight 23d ago
  Plan 9 had such a powerful model for networked systems using these virtual file systems, it sounds like a fairytale! 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!
  - mpweiher 23d ago
    Have a look at Objective-Smalltalk[1][2], with polymorphic identifiers[3] (all identifiers are URIs), storage combinators[4] (virtual filesystems on steroids), and polymorphic write streams[5] (streams everywhere). 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. [1] https://objective.st https://objective.st [2] https://dl.acm.org/doi/10.1145/3689492.3690052 https://dl.acm.org/doi/10.1145/3689492.3690052 [3] https://dl.acm.org/doi/10.1145/2508168.2508169 https://dl.acm.org/doi/10.1145/2508168.2508169 [4] https://2019.splashcon.org/details/splash-2019-Onward-papers/7/Storage-Combinators https://2019.splashcon.org/details/splash-2019-Onward-papers... [5] https://dl.acm.org/doi/10.1145/3359619.3359748 https://dl.acm.org/doi/10.1145/3359619.3359748
    - black_knight 23d ago
      Could you explain the connection you see a bit more? 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.
- ithkuil 23d ago
  I wonder if we're doing virtual filesystems wrong. 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
  - mpweiher 23d ago
    I think there is a good case to be made for these things not to be mediated by the operating system by default. In Objective-Smalltalk[1], I can access a file as follows: hello ← file:hello-world.txt This is structurally the same way I would access a local variable, environment variable, database, remote http server etc. hello ← https://example.com/hello-world.txt hello ← env:GREETING hello ← var:greeting // hello defaults to var:hello etc. And you can also introduce shortcuts scheme:greeter ← ref:https://example.com/ asScheme. hello ← greeter:hello-world.txt Or scheme:greeter ← ref:file:./ asScheme hello ← greeter:hello-world.txt Sending -asScheme to a reference is just a shorthand that actually constructs a composition[2] of a "path relative" store with the underlying store of the original reference. So the following two are identical: scheme:greeter ← ref:https://example.com/ asScheme. scheme:greeter ← #MPWRelativeScheme{ base: 'https://example/com' } → #MPWURLSchemeResolver{} This composition mechanism can be carried further with post-processing, so for example an img-scheme can be constructed by composing an image-decoder store with the previous store scheme:img ← #MPWImageDecoderStore{} → scheme:greeter helloPic ← img:wave.png And so on and so forth, caching is also a nice example. [1] https://objective.st https://objective.st [2] https://dl.acm.org/doi/10.1145/3359591.3359729 https://dl.acm.org/doi/10.1145/3359591.3359729
alphaentity 23d ago
[flagged]
gigatexal 23d ago
Funny this is hosted on GitHub pages
shevy-java 23d ago
> GitHub is still gigantic in both repos and minds, and its impact in the world of software development and collaboration in general has been enormous, and most likely it will continue to be. 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 ...).
jillesvangurp 23d ago
I half agree here. Now that the primary usage of Git is increasingly centered on providing auditable and revertible history for organizations that use a mix of AI (mostly) and people to do stuff with it, the requirements are going to shift away from being user friendly towards just being fit for purpose and efficient. 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?
- imtringued 23d ago
  AI makes running a deterministic workflow after a code change useless, because unlike humans, agents are not fallible, got it.
teiferer 23d ago
2/3 down the article I gave up. What are you trying to tell me? What is this revolution about? How are agent things fundamentally different and how are they being solved? What is this "second coming"? 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.
- colesantiago 23d ago
  I gave up after 5 seconds. Blog authors need a straight up TL;DR because I ain't reading all of that.
  - teiferer 23d ago
    Well, I like a good story, there is big potential in this long form stuff that's more than a tweet or two. There can be a great reward when the crux is revealed after building a foundation and then looking at it from different angles. But if that crux never comes then it's really just leaving a feeling of disappointment and waste of time that I invested into reading all this. And that does a disservice to everybody else writing blog posts. 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.)
    - thorum 23d ago
      FWIW, I flagged and downvoted both of your comments. The article is a very interesting overview of the space and recent developments, and having to scroll past multiple paragraphs about your low attention span and reading difficulties to get to some actual technical discussion was quite frustrating!
      - teiferer 23d ago
        Is flagging and downvoting really the right tool to express disagreement of opinion here? I disagree very much with what you just wrote, but I would not flag it. 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.
raegis 23d ago
Now that the revolution has apparently started, does anyone know of a version control system which uses encrypted storage? (I'm not concerned about performance, for I will use it for small projects only.)
- teiferer 23d ago
  Git on an encrypted volume?
  - raegis 21d ago
    Sorry, I did not specify the threat model. If I git push to an encrypted volume on a virtual server, like on Linode or Digital Ocean, anyone with access to the hardware can inspect unencrypted data on a live volume.
IshKebab 23d ago
> While we all stopped coding manually around December 2025 Come on at least say "many people". There are plenty of people still coding by hand.
rjsw 23d ago
People complained about having to use ClearCase back then, it wasn't just the price that was wrong with it.
- monster_truck 23d ago
  I helped swap a mess of ClearCase & Subversion over to git (early 2010s). What a fucking cursed piece of software! 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.
  - bitwize 23d ago
    > Software Bill of Materials Yet another thing that came from PRIDE, despite that PRIDE itself is little known in today's software industry.
  - theandrewbailey 23d ago
    My first programming job was an internal line of business application at a mortgage vending company. There was an uncomfortable amount of time wasted waiting for someone to do something in ClearCase so I could commit. I've turned down interviews solely on the basis that I would be using that dumpster fire of lost productivity and UX from hell.
- heisenbit 23d ago
  The author praises the enterprise version vs. the more simpler one. Having had the pleasure coordinating one clearcase site in a very large distributed setup with significant replication traffic and windows and unix clients: It was an unstable mess.
gmueckl 23d ago
It's great to see some moves to break up this great calcification around git. Gut greatest contribution to version control was stagnation. The space was evolving with great fresh ideas before git became a quasi-religion among the early adopters because Linus made it in a day and therefore it must be great or something. I'm exaggerating somewhat, but the zeal of some people back then was next level annoying. 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.
- throwawayqqq11 23d ago
  ... next, GNU please. /s
- dxdm 23d ago
  I don't think jujutsu is proprietary (unless you want to redefine that term). Source is freely available, and it uses Apache License 2.0. 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.
bargainbin 23d ago
I can accept the authors bias, but all credibility was gone when I read “AccuRev was a fantastic system”. AccuRevs UX was akin to putting your face next to a farting anus and breathing deeply. 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?
cynicalsecurity 23d ago
Not worth reading.
bob1029 23d ago
It sounds like the author went through a lot of pain to avoid using git+lfs or perforce. 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.
- MindSpunk 23d ago
  From my experience Git LFS is extremely brittle and will break your local check out if you so much as breath on it wrong. Perforce is an expensive solution to the problems of LFS, and I've yet to find a workflow as powerful as my git workflows for managing code. 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.
  - bob1029 22d ago
    Git and P4 are not meant to be directly competitive here. 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.
    - MindSpunk 22d ago
      > Git and P4 are not meant to be directly competitive here. 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.
mrkeen 23d ago
> If only 2 years ago somebody said GitHub would be no longer relevant soon, nobody would believe them. GitHub was the undisputed leader in repository hosting [..] > 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'.
pjmlp 23d ago
What second coming? If I had the option I would still be using either Mercurial or SVN. In fact, the way I use Git is hardly any different, I have no interest in getting a black belt in git magic.
foreigner 23d ago
The author mentions it briefly, but I'd like to see more exploration of what we can do differently now that we're all online all the time. I think that could potentially enable a Git-level revolution in the way we do things, similar to the way unlimited disk space did for Git.
asgeirn 23d ago
TLDR for those who gave up reading: 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.
vlfig 23d ago
Love the enthusiasm but I don't buy the two macro tailwinds he's counting on: ever larger monorepos & more centralisation. 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.
alansaber 23d ago
TL;DR better scale and concurrency. But really, just for for human-assisted AI swarms? I guess this is a cool concept if you think everyone will be handling 100+ agent swarms regularly?
1over137 23d ago
“and a sudden urge to replace GitHub.” Says someone making a blog post on github…
blahblaher 23d ago
what everyone wants is the code in those repos to train their AI, or train someone else's AI
not-so-darkstar 23d ago
why suddenly all websites look the same?
snovymgodym 22d ago
I think this article conflates GitHub and Git a few times, though the author definitely knows better. 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.

101 points by bananaboy 25d ago

Dreaming of "virtual filesystems everywhere". Hmm, sorta sounds like Plan 9. Great to have an inside view of wrangling technologies for these behemoth data sets.

forrestthewoods 23d ago
> virtual filesystems everywhere 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.
- ahartmetz 23d ago
  IMO screw that. It's maybe a good way to build software in exactly one environment for exactly one environment, deployment to a corporate server fleet. 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.
  - forrestthewoods 22d ago
    Deduping files is easy.
    - ahartmetz 22d ago
      It's also useless if every tool lives in its own copy of the universe - there'd be little to no identical files. It also won't work for version control databases, assuming use of a distributed VCS.
      - forrestthewoods 22d ago
        Yes it would require a global blob store across reps. That seems like a good design choice. I don’t know what you mean by “ won't work for version control databases, assuming use of a distributed VCS.”
        ahartmetz 21d ago
        The .git directory does not contain plain files, so the same files may look different in different .git directories. But yeah, you could make it work if you designed for it.
        forrestthewoods 21d ago
        Yeah Git is super mediocre. But the hypothesis is that you could build something that doesn’t suck!
- Kwpolska 23d ago
  Visual Studio and Xcode take up tens of gigabytes, are updated often, and include system components. Storing them in VCS is impossible, and would be a waste of disk space.
  - dist-epoch 23d ago
    You could consider ZFS a VCS, and it can easily store multiple versions (snapshots) of Visual Studio. It's not impossible, there just isn't that much demand for it.
  - maccard 23d ago
    Disagree. They’re stored _somewhwre_ anyway, and they may as well be versioned. 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
  - forrestthewoods 22d ago
    Literally not impossible. And also not tens of gigabytes.
black_knight 23d ago
Plan 9 had such a powerful model for networked systems using these virtual file systems, it sounds like a fairytale! 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!
- mpweiher 23d ago
  Have a look at Objective-Smalltalk[1][2], with polymorphic identifiers[3] (all identifiers are URIs), storage combinators[4] (virtual filesystems on steroids), and polymorphic write streams[5] (streams everywhere). 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. [1] https://objective.st https://objective.st [2] https://dl.acm.org/doi/10.1145/3689492.3690052 https://dl.acm.org/doi/10.1145/3689492.3690052 [3] https://dl.acm.org/doi/10.1145/2508168.2508169 https://dl.acm.org/doi/10.1145/2508168.2508169 [4] https://2019.splashcon.org/details/splash-2019-Onward-papers/7/Storage-Combinators https://2019.splashcon.org/details/splash-2019-Onward-papers... [5] https://dl.acm.org/doi/10.1145/3359619.3359748 https://dl.acm.org/doi/10.1145/3359619.3359748
  - black_knight 23d ago
    Could you explain the connection you see a bit more? 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.
ithkuil 23d ago
I wonder if we're doing virtual filesystems wrong. 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
- mpweiher 23d ago
  I think there is a good case to be made for these things not to be mediated by the operating system by default. In Objective-Smalltalk[1], I can access a file as follows: hello ← file:hello-world.txt This is structurally the same way I would access a local variable, environment variable, database, remote http server etc. hello ← https://example.com/hello-world.txt hello ← env:GREETING hello ← var:greeting // hello defaults to var:hello etc. And you can also introduce shortcuts scheme:greeter ← ref:https://example.com/ asScheme. hello ← greeter:hello-world.txt Or scheme:greeter ← ref:file:./ asScheme hello ← greeter:hello-world.txt Sending -asScheme to a reference is just a shorthand that actually constructs a composition[2] of a "path relative" store with the underlying store of the original reference. So the following two are identical: scheme:greeter ← ref:https://example.com/ asScheme. scheme:greeter ← #MPWRelativeScheme{ base: 'https://example/com' } → #MPWURLSchemeResolver{} This composition mechanism can be carried further with post-processing, so for example an img-scheme can be constructed by composing an image-decoder store with the previous store scheme:img ← #MPWImageDecoderStore{} → scheme:greeter helloPic ← img:wave.png And so on and so forth, caching is also a nice example. [1] https://objective.st https://objective.st [2] https://dl.acm.org/doi/10.1145/3359591.3359729 https://dl.acm.org/doi/10.1145/3359591.3359729

alphaentity 23d ago

[flagged]

gigatexal 23d ago

Funny this is hosted on GitHub pages

shevy-java 23d ago

> GitHub is still gigantic in both repos and minds, and its impact in the world of software development and collaboration in general has been enormous, and most likely it will continue to be. 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 ...).

jillesvangurp 23d ago

I half agree here. Now that the primary usage of Git is increasingly centered on providing auditable and revertible history for organizations that use a mix of AI (mostly) and people to do stuff with it, the requirements are going to shift away from being user friendly towards just being fit for purpose and efficient. 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?

imtringued 23d ago
AI makes running a deterministic workflow after a code change useless, because unlike humans, agents are not fallible, got it.

teiferer 23d ago

2/3 down the article I gave up. What are you trying to tell me? What is this revolution about? How are agent things fundamentally different and how are they being solved? What is this "second coming"? 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.

colesantiago 23d ago
I gave up after 5 seconds. Blog authors need a straight up TL;DR because I ain't reading all of that.
- teiferer 23d ago
  Well, I like a good story, there is big potential in this long form stuff that's more than a tweet or two. There can be a great reward when the crux is revealed after building a foundation and then looking at it from different angles. But if that crux never comes then it's really just leaving a feeling of disappointment and waste of time that I invested into reading all this. And that does a disservice to everybody else writing blog posts. 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.)
  - thorum 23d ago
    FWIW, I flagged and downvoted both of your comments. The article is a very interesting overview of the space and recent developments, and having to scroll past multiple paragraphs about your low attention span and reading difficulties to get to some actual technical discussion was quite frustrating!
    - teiferer 23d ago
      Is flagging and downvoting really the right tool to express disagreement of opinion here? I disagree very much with what you just wrote, but I would not flag it. 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.

raegis 23d ago

Now that the revolution has apparently started, does anyone know of a version control system which uses encrypted storage? (I'm not concerned about performance, for I will use it for small projects only.)

teiferer 23d ago
Git on an encrypted volume?
- raegis 21d ago
  Sorry, I did not specify the threat model. If I git push to an encrypted volume on a virtual server, like on Linode or Digital Ocean, anyone with access to the hardware can inspect unencrypted data on a live volume.

IshKebab 23d ago

> While we all stopped coding manually around December 2025 Come on at least say "many people". There are plenty of people still coding by hand.

rjsw 23d ago

People complained about having to use ClearCase back then, it wasn't just the price that was wrong with it.

monster_truck 23d ago
I helped swap a mess of ClearCase & Subversion over to git (early 2010s). What a fucking cursed piece of software! 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.
- bitwize 23d ago
  > Software Bill of Materials Yet another thing that came from PRIDE, despite that PRIDE itself is little known in today's software industry.
- theandrewbailey 23d ago
  My first programming job was an internal line of business application at a mortgage vending company. There was an uncomfortable amount of time wasted waiting for someone to do something in ClearCase so I could commit. I've turned down interviews solely on the basis that I would be using that dumpster fire of lost productivity and UX from hell.
heisenbit 23d ago
The author praises the enterprise version vs. the more simpler one. Having had the pleasure coordinating one clearcase site in a very large distributed setup with significant replication traffic and windows and unix clients: It was an unstable mess.

gmueckl 23d ago

It's great to see some moves to break up this great calcification around git. Gut greatest contribution to version control was stagnation. The space was evolving with great fresh ideas before git became a quasi-religion among the early adopters because Linus made it in a day and therefore it must be great or something. I'm exaggerating somewhat, but the zeal of some people back then was next level annoying. 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.

throwawayqqq11 23d ago
... next, GNU please. /s
dxdm 23d ago
I don't think jujutsu is proprietary (unless you want to redefine that term). Source is freely available, and it uses Apache License 2.0. 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.

bargainbin 23d ago

I can accept the authors bias, but all credibility was gone when I read “AccuRev was a fantastic system”. AccuRevs UX was akin to putting your face next to a farting anus and breathing deeply. 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?

cynicalsecurity 23d ago

Not worth reading.

bob1029 23d ago

It sounds like the author went through a lot of pain to avoid using git+lfs or perforce. 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.

MindSpunk 23d ago
From my experience Git LFS is extremely brittle and will break your local check out if you so much as breath on it wrong. Perforce is an expensive solution to the problems of LFS, and I've yet to find a workflow as powerful as my git workflows for managing code. 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.
- bob1029 22d ago
  Git and P4 are not meant to be directly competitive here. 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.
  - MindSpunk 22d ago
    > Git and P4 are not meant to be directly competitive here. 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.

mrkeen 23d ago

> If only 2 years ago somebody said GitHub would be no longer relevant soon, nobody would believe them. GitHub was the undisputed leader in repository hosting [..] > 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'.

pjmlp 23d ago

What second coming? If I had the option I would still be using either Mercurial or SVN. In fact, the way I use Git is hardly any different, I have no interest in getting a black belt in git magic.

foreigner 23d ago

The author mentions it briefly, but I'd like to see more exploration of what we can do differently now that we're all online all the time. I think that could potentially enable a Git-level revolution in the way we do things, similar to the way unlimited disk space did for Git.

asgeirn 23d ago

TLDR for those who gave up reading: 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.

vlfig 23d ago

Love the enthusiasm but I don't buy the two macro tailwinds he's counting on: ever larger monorepos & more centralisation. 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.

alansaber 23d ago

TL;DR better scale and concurrency. But really, just for for human-assisted AI swarms? I guess this is a cool concept if you think everyone will be handling 100+ agent swarms regularly?

1over137 23d ago

“and a sudden urge to replace GitHub.” Says someone making a blog post on github…

blahblaher 23d ago

what everyone wants is the code in those repos to train their AI, or train someone else's AI

not-so-darkstar 23d ago

why suddenly all websites look the same?

snovymgodym 22d ago

I think this article conflates GitHub and Git a few times, though the author definitely knows better. 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.