In a 2022 survey by Stack Overflow, Git had a market share of 94%, ...
Never in history has a version control system dominated the market like Git. What will be the next to replace Git? Many say it might be related to AI, but no one can say for sure.
I doubt it's getting replaced. It's not just that it's got so much of the market, but also that the market is so much larger than back in the days of CVS.
It's hard to imagine everyone switching from Git. Switching from GitHub, feasible. From Git? That's much harder.
Git shortcomings are well known by this point, so "all" a successor project has to do is solve those problems. Git scales to Linux kernel sized projects, but it turns out there are bigger, even more complex projects out there, so it doesn't scale to Google-sized organizations. You would want to support centralized and decentralized operation, but be aware of both, so it would support multiple remotes, while making it easier to keep them straight. Is the copy on Github up to date with gitlab, the CI system, and my laptop and my desktop? It would have to handle binaries well, and natively, so I can check-in my 100 MiB jpeg and not stuff things up. You'd want to use it both as a monorepo and as multirepos, by allowing you to checkout just a subtree of the monorepo. Locally, the workflow would need to both support git's complexity, while also being easier to use than git.
Anyway, those are the four things you'd have to hit in order to replace git, as I see them.
If you had such a system, getting people off git wouldn't be the issue - offer git compatibility and if they don't want to use the advanced features, they can just keep using their existing workflow with git. The problem with that though, is that then why use your new system.
Which gets to the point of, how do you make this exist as a global worldwide product? FAANG-sized companies have their own internal tools team to manage source code. Anywhere smaller doesn't have the budget to create such a thing from scratch but
You can't go off and make this product and then sell it to someone because how many companies are gonna go with an unproven new workflow tool that their engineers want? What's the TAM of companies for whom "git's not good enough", and have large enough pocketbooks?
You are right. GIT is not DVFS, its DVCS. It was made to track source code, not binary data. If you are putting binary to DVCS, you are doing something wrong.
But, there are industries that need it, like game industry. So they should use tool that allow that. I heard that Plastic-SCM is pretty decent at it. Never used it so cant tell personally.
Replacing GIT is such a stupid idea. There is no ONE tool to handle all cases. Just use right one for your workflows. I, for example, have a need to version binary files. I know GIT handles them badly, but I really like the tool. Solution? I wrote my own simple DVFS tool for that usecase: dot.exe (138KB)
Its very simple DVFS for personal use, peer to peer syncing (local, TCP, SSH). Data and Metadata are SHA-1 checksumed. Its pretty speedy for my needs :) After weeks of use use I liked it so much, I added pack storage to handle text files and moved all my notes from SVN to DOT :)
Second that way of thinking, for me GIT is as good as it gets for versioning text files.
Not handling binary files is not a downside for me because GIT should not be a tool to handle binary files versioning and we should use something else for that.
What do you use when you have a tiny .png or .jpg that needs to live alongside your source code now?
I can put a binary file in GIT repo especially small ones and ones that don't change - things that people want are "handling binary files well", whatever that means, but putting big binaries in GIT or a lot of binary files or versioning them is not the use case for GIT.
Just put it in your git repo.
Isn't there git-annex [0] if you want to store large binary files?
[0] https://git-annex.branchable.com/
Yeah I know about git-annex. It might be good solution for big data. In my case, I do NOT want to decouple storage from metadata. I want single repo for single project that is self-contained. Easier to manage, its truly distributed. No need to bother w/ backups because every replica have everything allready. Its good model for several GBs of data.
DVCS stands for distributed version control system, it has nothing to do with source code?
Maybe you're confusing it with SCM which are source control managers, that's the only ones that handle strict source only, but scm can mean other things.
Hard to say.. For me DVCS is more advanced version of DVFS. DVCS can do branching and merging, provides more metadata for revisions etc.. DVFS just do pretty much one thing, store binary blobs. And because binary blobs cannot be easly merged, I would not use it for storage here. But I guess, its just me :)
You say this, but Git has made great strides in scaling to huge repositories in recent years. You can currently do the "checkout just a subtree of the monorepo" just fine, and you can use shallow clones to approximate a centralized system (and most importantly to use less local storage).
Git is already doing exactly that.
Git itself isn’t though, not in any real way that matters. Having to know all the sub trees to clone in a mono repo is a usability nonstarter. You need a pseudo filesystem that knows how to pull files on access. And one ideally integrated with the build system to offset the cost of doing remote operations on demand and improve parallelism. Facebook is open sourcing a lot of their work but it’s based on mercurial. Microsoft is bought into git but afaik hasn’t open sourced their supporting git tooling that makes this feasible.
TLDR: the problem is more complex and pretending like “you can checkout a subtree” solves the problem is missing the proverbial forest for the (sub)tree
Microsoft's vfs for git is open source. So is scalar. These are the two main approaches used at Microsoft for large repos. Unfortunately the technically superior vfs approach was a nonstarter on macOS.
How do I check out, eg https://github.com/neovim/neovim/tree/master/scripts into a directory and work with it as if it was a repo unto itself?
You can't (since commits are snapshots of the repo root). You can have this approximation however:
Unfortunately, GitHub does not support --filter=sparse:oid=master:scripts, so blobs will be fetched on demand as you use the repo.It does feel like asking "What will replace ASCII?" Extensions, sure, but 0x41 is going to mean 'A' in 5050 AD.
UTF-8
That validates gp's point though: UTF-8 doesn't replace ASCII, it extends it. All valid ASCII text remains valid UTF-8 while retaining the same meaning. With the momentum behind git it will be hard for something incompatible replace it, but an extended git could catch on.
Author here. I don’t think ASCII is the right comparison. True, it would be really hard for anything to compete with Git because a lot of infrastructures we have are already deeply integrated with Git. But think about x86 vs. ARM and how AI might change our ways of producing code.
I really doubt that would happen. Got fails when it reaches Google scale repos. But most of the world isn't using such large repos anyway.
A replacement would be niche, only for the huge orgs, which is usually made by them anyway. For everyone else, git is good enough.