16 ms·

This is well written and deserves my upvote, because sparse-checkout is part of git and knowing how it works is useful. That said, there's absolutely no reason

This is well written and deserves my upvote, because sparse-checkout is part of git and knowing how it works is useful. That said, there's absolutely no reason to structure your code in a monorepo. Here's what I think GitHub is doing: 1) Encourage monorepo adoption 2) Build tooling for monorepos 3) Selling tooling to developers stranded in monorepos Microsoft, which owns GitHub, created the microsoft/git fork linked in the article, and they explain their justification here: https://github.com/microsoft/git#why-is-this-fork-needed https://github.com/microsoft/git#why-is-this-fork-needed > Well, because Git is a distributed version control system, each Git repository has a copy of all files in the entire history. As large repositories, aka monorepos grow, Git can struggle to manage all that data. As Git commands like status and fetch get slower, developers stop waiting and start switching context. And context switches harm developer productivity. I believe that Google's brand is so big that it led to this mass cognitive dissonance, which is being exploited by GitHub. To be clear, here are the two ideas in conflict: * Git is decentralized and fast, and Google famously doesn't use it. * Companies want to use "industry standard" tech, and Google is the standard for success. Now apply those observations to a world where your engineers only use "git". The result is market demand to misuse git for monorepos, which Microsoft is pouring huge amounts of resources into enabling via GitHub. It makes great sense that GitHub wants to lean into this. More centralization and being more reliant on GitHub's custom tooling is obviously better for GitHub. It just so happens that GitHub is building tools to enable monorepos, essentially normalizing their usage. Then GitHub can sell tools to deal with your enormous monorepo, because your traditional tools will feel slow and worse than GitHub's tools. In other words, GitHub is propping up the failed monorepo idea as a strategy to get people in the pipeline for things like CodeSpaces: https://github.com/features/codespaces https://github.com/features/codespaces Because if you have 100 projects and they're all separate, you can do development locally for each and it's fast and sensible. But if all your projects are in one repo, the tools grind to a halt, and suddenly you need to buy a solution that just works to meet your business goals.

ratww 5y ago
> That said, there's absolutely no reason to structure your code in a monorepo. Bullshit. There are very good reasons to use it in some situations. My company is using it and it's a tremendous productivity boon. And Git works perfectly fine for smaller scales. Obviously, "because Google does it" is a terrible reason. But it's disingenuous to say that's the only reason people are doing it. Not everyone is a moron.
- anon9001 5y ago
  I'm glad you're having a good experience now, and git as a monorepo will work fine at smaller scales, but you will outgrow it at some point. When you do, you have two choices. You can either commit to the monorepo direction and start using non-standard tooling that sacrifices decentralization, or you can break up your repo into smaller manageable repos. I don't have any problem with small organizations throwing everything into one git repo because it's convenient. My objection is that when you eventually do hit the limits of git, will you choose to break the fundamentals of git decentralization as a workaround? Or will you break up the repo into a couple of other repos with specific purposes? I don't like that GitHub makes money by encouraging people to make the wrong choice at that juncture.
  - rsj_hn 5y ago
    > I'm glad you're having a good experience now, and git as a monorepo will work fine at smaller scales, but you will outgrow it at some point. I would say the opposite. A lot of companies are fine with independent teams using their own versions of dependencies and their own versions of core code, but at some point that becomes unmanageable and you need to start using a common set of dependencies and the same version of base frameworks to reduce the complexity. That means pushing a patch to a framework means all the teams are upgraded. Monorepos are the most common solution to enforce that behavior. Look, this is all dealing with the problem of coordination in large teams. Different organizations have different capacities for coordination, and so it's like squeezing a balloon -- yes, you want more agility to pick your own deps but then the cost of that is dealing with so much complexity when you need to push a fix to a commonly used framework or when a CVE is found in a widely used dep and needs to be updated by 1000 different teams all manually. There is no "right" way. It's just something organizations have to struggle with because it's going to be costly no matter what, and all that matters is what type of cost your org is most easily able to bear. That will decide whether you use a monorepo or a bunch of independent repos, whether you go for microservices or a monolith, and most companies will do some mix of all of the above.
    - anon9001 5y ago
Orphis 5y ago
> Git is decentralized and fast, and Google famously doesn't use it. Most (all?) of Google OSS software is hosted on either Gerrit or Github. Git is not used by the "google3" monorepo, but it's used by quite a few major projects.
tsimionescu 5y ago
Monorepos are much easier for everyone to use, and are the only natural way to manage code for any project. You keep talking about Google, but a much more famous monorepo is Linux itself. Perhaps Linus Torvalds has fallen into Google's hype? The fact that git is very poor at scaling monorepos might mean that it's a bad idea to use git for larger organizations, not that it's a bad idea to use monorepos. If git can be improved to work with monorepos, all the better.
- anon9001 5y ago
  > Monorepos are much easier for everyone to use, and are the only natural way to manage code for any project. I strongly disagree with that, but I'll let this blog post explain it better than I can: https://medium.com/@mattklein123/monorepos-please-dont-e9a279be011b https://medium.com/@mattklein123/monorepos-please-dont-e9a27... > You keep talking about Google, but a much more famous monorepo is Linux itself. I thought it was fairly well known that monorepos came directly from Google as part of their SRE strategy. It didn't even come into common usage until around 2017 (according to wikipedia). If I'm remembering correctly, the SRE book recommends it, and that's why it gained popularity. Also, I don't believe that Linux is a valid interpretation of "monorepo". Linux is a singular product. You can't build the kernel without all of the parts. A better example would be if there was a "Linus" repo that contained both git and linux. There isn't, and for good reason. > The fact that git is very poor at scaling monorepos might mean that it's a bad idea to use git for larger organizations, not that it's a bad idea to use monorepos. If git can be improved to work with monorepos, all the better. Any performance improvement in git is welcome, but anything that sacrifices a full clone of the entire repository is antithetical to decentralization. The whole point of git is decentralized source code.
  - cdcarter 5y ago
    I think it's at least somewhat fair to call Linux a monorepo. There are a lot of drivers included in the main tree. They don't need to be, (we know this because there are also lots of drivers not in the source tree). But by including them, the kernel devs can make large changes to the API and all the drivers in one go. This is a classic "why use a monorepo".
omegalulw 5y ago
Your take is extremely biased. You only just discuss why monorepos are bad. Here's some of the many reasons why monorepos are excellent: - Continuous integration. Every project is almost always using the lastest code from other projects and libraries it depends on. - Builds from scratch are very easy and don't need extravagant tooling. - Problems due to build versions in dependency management are reduced (everyone is expected to use HEAD). - The whole organization settles on a common build patterns - so if you want to add a new dependency you wouldn't need to struggle with their build system. Conversely, you need to write lesser documentation on how to build your code - cause that's now standard.
- anon9001 5y ago
  Heh, the major problems that I've run into using monorepos in the real world at scale are: - CI breaks all the time. Even one temperamental test from anywhere else in the organization can cause your CI run to fail. - Building the monorepo locally becomes very complicated, even to just get your little section running. Now all developers need all the tools used in the monorepo. - Dependencies get upgraded unexpectedly. Tests aren't perfect, so people upgrade dependencies and your code inevitably breaks. It's cool that everyone is on the same coding style, but that's very much achievable with a shared linter configuration.
  - dlp211 5y ago
    Your problem isn't monorepo, it's bad tooling. Tests should only execute against code that changed. Builds should only build the thing you want to build, not the whole repository.
    - anon9001 5y ago
      Yes! The problem is choosing a monorepo because the tooling isn't suited for monorepos. Trying to build a monorepo with git is like trying to build your CRUD web app frontend in c++. Sure, you can do it. Webassembly exists and clang can compile to it. I wouldn't recommend it because the tooling doesn't match your actual problem. Or maybe a better example is that it's like deciding the browser widgets aren't very good, so we'll re-render our own custom widgets with WebGL. Yes, this is all quite possible, and your result might get to some definition of "better", but you're not really solving the problem you had of building a CRUD web app. Can Microsoft successfully shim git so that it appears like a centralized trunk-based monorepo, the way you'd find at an old cvs/svn/perforce shop? Yes, they did, but they shouldn't have. My thesis is they're only pushing monorepos because it helps GitHub monetize, and I stand by that. > Tests should only execute against code that changed. Builds should only build the thing you want to build, not the whole repository. How do you run your JS monorepo? Did you somehow get bazel to remote cache a webpack build into individual objects, so you're only building the changes? Can this even be done with a modern minimization tool in the pipeline? Is there another web packager that does take a remotely cachable object-based approach? I don't know enough about JS build systems to make a monorepo work in any sensible way that utilizes caching and minimizes build times. If anything good comes out of the monorepo movement, it will be a forcing function that makes JS transpilers more cacheable. And all this for what? Trunk-based development? So we can get surprise dependency updates? So that some manager feels good that all the code is in one directory? The reason Linus invented git in the first place was because decentralized is the best way to build software. He literally stopped work on the kernel for 2 weeks to build the first version of git because the scale by which he could merge code was the superpower that grew Linux. If you YouTube search for "git linus" you can listen to the original author explain the intent from 14 years ago: https://www.youtube.com/watch?v=4XpnKHJAok8 https://www.youtube.com/watch?v=4XpnKHJAok8 If this is a topic you're passionate about, I'd encourage you to watch that video, as he addresses why decentralizing is so important and how it makes for healthy software projects. It's also fun to watch old Googlers not "get it". He was right then and he's right now. It's disappointing to see so much of HN not get it.
jeffbee 5y ago
> Git is ... fast, and Google ... doesn't use it. Everything about git is orders of magnitude slower than the monorepo in use at Google. Git is not fast, and its slowness scales with the size of your repo.
ajkjk 5y ago
Very much doubt that's their corporate strategy. More likely it's as simple as: lots of people have monorepos; they have lots of issues with Git and Github; Github wants their business.
solarmist 5y ago
From my understanding Microsoft is doing it because they want to use git for developing windows which is(was?) a large monorepo.
saghm 5y ago
> Then GitHub can sell tools to deal with your enormous monorepo, because your traditional tools will feel slow and worse than GitHub's tools The "tool" in this case is a feature being added to upstream git, which everyone gets for free. It seems reasonable to assume other git providers will also be adding support for it server-side where needed; I have to imagine Gitlab either already is or will be doing work to support monorepos as well, assuming there's enough demand for it. At worst, this seems like it could be trying to lock people into git generally rather than GitHub specifically, but more likely this is just work being done to support something that (potential) customers are already asking for.

ratww 5y ago

> That said, there's absolutely no reason to structure your code in a monorepo. Bullshit. There are very good reasons to use it in some situations. My company is using it and it's a tremendous productivity boon. And Git works perfectly fine for smaller scales. Obviously, "because Google does it" is a terrible reason. But it's disingenuous to say that's the only reason people are doing it. Not everyone is a moron.

anon9001 5y ago
I'm glad you're having a good experience now, and git as a monorepo will work fine at smaller scales, but you will outgrow it at some point. When you do, you have two choices. You can either commit to the monorepo direction and start using non-standard tooling that sacrifices decentralization, or you can break up your repo into smaller manageable repos. I don't have any problem with small organizations throwing everything into one git repo because it's convenient. My objection is that when you eventually do hit the limits of git, will you choose to break the fundamentals of git decentralization as a workaround? Or will you break up the repo into a couple of other repos with specific purposes? I don't like that GitHub makes money by encouraging people to make the wrong choice at that juncture.
- rsj_hn 5y ago
  > I'm glad you're having a good experience now, and git as a monorepo will work fine at smaller scales, but you will outgrow it at some point. I would say the opposite. A lot of companies are fine with independent teams using their own versions of dependencies and their own versions of core code, but at some point that becomes unmanageable and you need to start using a common set of dependencies and the same version of base frameworks to reduce the complexity. That means pushing a patch to a framework means all the teams are upgraded. Monorepos are the most common solution to enforce that behavior. Look, this is all dealing with the problem of coordination in large teams. Different organizations have different capacities for coordination, and so it's like squeezing a balloon -- yes, you want more agility to pick your own deps but then the cost of that is dealing with so much complexity when you need to push a fix to a commonly used framework or when a CVE is found in a widely used dep and needs to be updated by 1000 different teams all manually. There is no "right" way. It's just something organizations have to struggle with because it's going to be costly no matter what, and all that matters is what type of cost your org is most easily able to bear. That will decide whether you use a monorepo or a bunch of independent repos, whether you go for microservices or a monolith, and most companies will do some mix of all of the above.
  - anon9001 5y ago

Orphis 5y ago

> Git is decentralized and fast, and Google famously doesn't use it. Most (all?) of Google OSS software is hosted on either Gerrit or Github. Git is not used by the "google3" monorepo, but it's used by quite a few major projects.

tsimionescu 5y ago

Monorepos are much easier for everyone to use, and are the only natural way to manage code for any project. You keep talking about Google, but a much more famous monorepo is Linux itself. Perhaps Linus Torvalds has fallen into Google's hype? The fact that git is very poor at scaling monorepos might mean that it's a bad idea to use git for larger organizations, not that it's a bad idea to use monorepos. If git can be improved to work with monorepos, all the better.

anon9001 5y ago
> Monorepos are much easier for everyone to use, and are the only natural way to manage code for any project. I strongly disagree with that, but I'll let this blog post explain it better than I can: https://medium.com/@mattklein123/monorepos-please-dont-e9a279be011b https://medium.com/@mattklein123/monorepos-please-dont-e9a27... > You keep talking about Google, but a much more famous monorepo is Linux itself. I thought it was fairly well known that monorepos came directly from Google as part of their SRE strategy. It didn't even come into common usage until around 2017 (according to wikipedia). If I'm remembering correctly, the SRE book recommends it, and that's why it gained popularity. Also, I don't believe that Linux is a valid interpretation of "monorepo". Linux is a singular product. You can't build the kernel without all of the parts. A better example would be if there was a "Linus" repo that contained both git and linux. There isn't, and for good reason. > The fact that git is very poor at scaling monorepos might mean that it's a bad idea to use git for larger organizations, not that it's a bad idea to use monorepos. If git can be improved to work with monorepos, all the better. Any performance improvement in git is welcome, but anything that sacrifices a full clone of the entire repository is antithetical to decentralization. The whole point of git is decentralized source code.
- cdcarter 5y ago
  I think it's at least somewhat fair to call Linux a monorepo. There are a lot of drivers included in the main tree. They don't need to be, (we know this because there are also lots of drivers not in the source tree). But by including them, the kernel devs can make large changes to the API and all the drivers in one go. This is a classic "why use a monorepo".

omegalulw 5y ago

Your take is extremely biased. You only just discuss why monorepos are bad. Here's some of the many reasons why monorepos are excellent: - Continuous integration. Every project is almost always using the lastest code from other projects and libraries it depends on. - Builds from scratch are very easy and don't need extravagant tooling. - Problems due to build versions in dependency management are reduced (everyone is expected to use HEAD). - The whole organization settles on a common build patterns - so if you want to add a new dependency you wouldn't need to struggle with their build system. Conversely, you need to write lesser documentation on how to build your code - cause that's now standard.

anon9001 5y ago
Heh, the major problems that I've run into using monorepos in the real world at scale are: - CI breaks all the time. Even one temperamental test from anywhere else in the organization can cause your CI run to fail. - Building the monorepo locally becomes very complicated, even to just get your little section running. Now all developers need all the tools used in the monorepo. - Dependencies get upgraded unexpectedly. Tests aren't perfect, so people upgrade dependencies and your code inevitably breaks. It's cool that everyone is on the same coding style, but that's very much achievable with a shared linter configuration.
- dlp211 5y ago
  Your problem isn't monorepo, it's bad tooling. Tests should only execute against code that changed. Builds should only build the thing you want to build, not the whole repository.
  - anon9001 5y ago
    Yes! The problem is choosing a monorepo because the tooling isn't suited for monorepos. Trying to build a monorepo with git is like trying to build your CRUD web app frontend in c++. Sure, you can do it. Webassembly exists and clang can compile to it. I wouldn't recommend it because the tooling doesn't match your actual problem. Or maybe a better example is that it's like deciding the browser widgets aren't very good, so we'll re-render our own custom widgets with WebGL. Yes, this is all quite possible, and your result might get to some definition of "better", but you're not really solving the problem you had of building a CRUD web app. Can Microsoft successfully shim git so that it appears like a centralized trunk-based monorepo, the way you'd find at an old cvs/svn/perforce shop? Yes, they did, but they shouldn't have. My thesis is they're only pushing monorepos because it helps GitHub monetize, and I stand by that. > Tests should only execute against code that changed. Builds should only build the thing you want to build, not the whole repository. How do you run your JS monorepo? Did you somehow get bazel to remote cache a webpack build into individual objects, so you're only building the changes? Can this even be done with a modern minimization tool in the pipeline? Is there another web packager that does take a remotely cachable object-based approach? I don't know enough about JS build systems to make a monorepo work in any sensible way that utilizes caching and minimizes build times. If anything good comes out of the monorepo movement, it will be a forcing function that makes JS transpilers more cacheable. And all this for what? Trunk-based development? So we can get surprise dependency updates? So that some manager feels good that all the code is in one directory? The reason Linus invented git in the first place was because decentralized is the best way to build software. He literally stopped work on the kernel for 2 weeks to build the first version of git because the scale by which he could merge code was the superpower that grew Linux. If you YouTube search for "git linus" you can listen to the original author explain the intent from 14 years ago: https://www.youtube.com/watch?v=4XpnKHJAok8 https://www.youtube.com/watch?v=4XpnKHJAok8 If this is a topic you're passionate about, I'd encourage you to watch that video, as he addresses why decentralizing is so important and how it makes for healthy software projects. It's also fun to watch old Googlers not "get it". He was right then and he's right now. It's disappointing to see so much of HN not get it.

jeffbee 5y ago

> Git is ... fast, and Google ... doesn't use it. Everything about git is orders of magnitude slower than the monorepo in use at Google. Git is not fast, and its slowness scales with the size of your repo.

ajkjk 5y ago

Very much doubt that's their corporate strategy. More likely it's as simple as: lots of people have monorepos; they have lots of issues with Git and Github; Github wants their business.

solarmist 5y ago

From my understanding Microsoft is doing it because they want to use git for developing windows which is(was?) a large monorepo.

saghm 5y ago

> Then GitHub can sell tools to deal with your enormous monorepo, because your traditional tools will feel slow and worse than GitHub's tools The "tool" in this case is a feature being added to upstream git, which everyone gets for free. It seems reasonable to assume other git providers will also be adding support for it server-side where needed; I have to imagine Gitlab either already is or will be doing work to support monorepos as well, assuming there's enough demand for it. At worst, this seems like it could be trying to lock people into git generally rather than GitHub specifically, but more likely this is just work being done to support something that (potential) customers are already asking for.