4 ms·

That was what I expected from the description as well. After reading the readme it's not clear to me what problem this is trying to solve, and why this is the s

by lbhdc 5y ago

That was what I expected from the description as well. After reading the readme it's not clear to me what problem this is trying to solve, and why this is the solution.

ganafagol 5y ago
The problem is that large codebases tend to have a huge footprint if you need to clone the whole repo. Git as-is does not allow you to only pull a subset, i.e. specific paths representing a sub project. That's what josh is trying to solve: a "virtual" repo that behaves like a real git repo but behind the scenes seemlessly integrates with the big monorepo.
- mumblemumble 5y ago
  Whereas what I was kind of hoping for was something that works like svn externals. (No, git submodules are not it.)
- lbhdc 5y ago
  I believe git provides that functionality through sparse-checkout. You can clone a repository without checking it out, then use sparse-checkout to only pull the paths you want.
  - rcxdude 5y ago
    sparse-checkout only reduces the number of files copied from the local repo to the working directory. It doesn't affect the amount downloaded data. For that you need shallow and partial clones (shallow clones give you a subset of history, partial clones give you a subset of the files within that history). Partial clones especially are a relatively new and not heavily used git feature.
    - varajelle 5y ago
      Partial clone with the --filter feature seems complicated to use. You need to use a bunch of command to set it up and then it looks like you still need to be careful while using it. I'd dream of somethong as simple as git clone --partial foo/bar https://example.com/some.repo.git And then everything would work normally.
      - chrschilling 5y ago
        Your dream came true ;) This is what Josh does: git clone https://example.com/some.repo.git:/foo/bar.git And then everything works normally.
- Jenk 5y ago
  disclaimer: I haven't seen for myself what benefits monorepos actually provide so I don't fully grok them. This is the kind of talk about monorepos that makes me think they are a bad idea. Why would someone want to maintain a monorepo and then pretend it's not a monorepo? Not only just pretend it isn't, but invest not-insignificant time on the problem of pretending it's not a monorepo? I am immediately thinking of the horribleness of how some of the (older) javascript frameworks re-invented the back button (and browser history in general) instead of.. ya know, using the browser.
  - gumby 5y ago
    One big advantage of a monorepo is that when you check out the tree you automatically get the versions of all the files that work together (assuming there's some CI!). If you want to refactor an API you can refactor its callers easily and check the whole thing in. Etc. With each project having its own repo, then you have to track the fact that Foobar 2.2 works with baizo 1.6-1.8 but not more recent versions. Also conceptually it's easier when you are working with the client and the server at the same time, or the two mobile apps, and so on. Of course people manage without this when the project has stuff that doesn't fit in a software repo (CAD designs, artwork, etc...there's a reason why that POS Perforce survives, for example). Solidworks has its own proprietary RCS that doesn't work with anything else. IMHO if the project is relatively small (say <500K LoC) a monorepo is almost always the way to go. But with a big project it breaks down.
    - beagle3 5y ago
      It’s basic git that breaks down, not the monorepo model. And it’s less about LoC, and more about the number of files and how much binary stuff you put in your repo (and how often it changes). Git is really bad when binary data is involved. Git has the facilities to keep monorepos clicking along (shallow clones and sparse checkout) but they aren’t along the “happy path”
      - drjasonharrison 5y ago
        And many git repository hosting services, like bitbucket, have limits on how large your repository can be. Sometimes you can upgrade these limits. This often leads to fear of exceeding this limit and can lead to one repository per module.

by lbhdc 5y ago

That was what I expected from the description as well. After reading the readme it's not clear to me what problem this is trying to solve, and why this is the solution.

ganafagol 5y ago

The problem is that large codebases tend to have a huge footprint if you need to clone the whole repo. Git as-is does not allow you to only pull a subset, i.e. specific paths representing a sub project. That's what josh is trying to solve: a "virtual" repo that behaves like a real git repo but behind the scenes seemlessly integrates with the big monorepo.

mumblemumble 5y ago
Whereas what I was kind of hoping for was something that works like svn externals. (No, git submodules are not it.)
lbhdc 5y ago
I believe git provides that functionality through sparse-checkout. You can clone a repository without checking it out, then use sparse-checkout to only pull the paths you want.
- rcxdude 5y ago
  sparse-checkout only reduces the number of files copied from the local repo to the working directory. It doesn't affect the amount downloaded data. For that you need shallow and partial clones (shallow clones give you a subset of history, partial clones give you a subset of the files within that history). Partial clones especially are a relatively new and not heavily used git feature.
  - varajelle 5y ago
    Partial clone with the --filter feature seems complicated to use. You need to use a bunch of command to set it up and then it looks like you still need to be careful while using it. I'd dream of somethong as simple as git clone --partial foo/bar https://example.com/some.repo.git And then everything would work normally.
    - chrschilling 5y ago
      Your dream came true ;) This is what Josh does: git clone https://example.com/some.repo.git:/foo/bar.git And then everything works normally.
Jenk 5y ago
disclaimer: I haven't seen for myself what benefits monorepos actually provide so I don't fully grok them. This is the kind of talk about monorepos that makes me think they are a bad idea. Why would someone want to maintain a monorepo and then pretend it's not a monorepo? Not only just pretend it isn't, but invest not-insignificant time on the problem of pretending it's not a monorepo? I am immediately thinking of the horribleness of how some of the (older) javascript frameworks re-invented the back button (and browser history in general) instead of.. ya know, using the browser.
- gumby 5y ago
  One big advantage of a monorepo is that when you check out the tree you automatically get the versions of all the files that work together (assuming there's some CI!). If you want to refactor an API you can refactor its callers easily and check the whole thing in. Etc. With each project having its own repo, then you have to track the fact that Foobar 2.2 works with baizo 1.6-1.8 but not more recent versions. Also conceptually it's easier when you are working with the client and the server at the same time, or the two mobile apps, and so on. Of course people manage without this when the project has stuff that doesn't fit in a software repo (CAD designs, artwork, etc...there's a reason why that POS Perforce survives, for example). Solidworks has its own proprietary RCS that doesn't work with anything else. IMHO if the project is relatively small (say <500K LoC) a monorepo is almost always the way to go. But with a big project it breaks down.
  - beagle3 5y ago
    It’s basic git that breaks down, not the monorepo model. And it’s less about LoC, and more about the number of files and how much binary stuff you put in your repo (and how often it changes). Git is really bad when binary data is involved. Git has the facilities to keep monorepos clicking along (shallow clones and sparse checkout) but they aren’t along the “happy path”
    - drjasonharrison 5y ago
      And many git repository hosting services, like bitbucket, have limits on how large your repository can be. Sometimes you can upgrade these limits. This often leads to fear of exceeding this limit and can lead to one repository per module.