4 ms·

> 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 wi

> 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.

jbaber 2y ago
It does feel like asking "What will replace ASCII?" Extensions, sure, but 0x41 is going to mean 'A' in 5050 AD.
- eliangcs 2y ago
  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.
- mmphosis 2y ago
  UTF-8
  - account42 2y ago
    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.
fragmede 2y ago
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?
- Borg3 2y ago
  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 :)
  - ozim 2y ago
    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.
    - fragmede 2y ago
      What do you use when you have a tiny .png or .jpg that needs to live alongside your source code now?
      - nolist_policy 2y ago
        Just put it in your git repo.
      - ozim 2y ago
        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.
langsoul-com 2y ago
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.

jbaber 2y ago

It does feel like asking "What will replace ASCII?" Extensions, sure, but 0x41 is going to mean 'A' in 5050 AD.

eliangcs 2y ago
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.
mmphosis 2y ago
UTF-8
- account42 2y ago
  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.

fragmede 2y ago

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?

Borg3 2y ago
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 :)
- ozim 2y ago
  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.
  - fragmede 2y ago
    What do you use when you have a tiny .png or .jpg that needs to live alongside your source code now?
    - nolist_policy 2y ago
      Just put it in your git repo.
    - ozim 2y ago
      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.

langsoul-com 2y ago

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.