4 ms·

I've come to learn that git monorepos are becoming quite popular. What I don't understand is why people are using git for this kind of workflow. It forces you t

I've come to learn that git monorepos are becoming quite popular. What I don't understand is why people are using git for this kind of workflow. It forces you to actively work against git's design goals and implementation. Which then compels the use of several odd workarounds and kludges to kind of seemingly reassemble a half-baked flavor of subversion. Why not just use a tool designed around monorepos and subtrees? I'm genuinely curious. I assume I'm missing something.

endisneigh 5y ago
What are these tools designed for monorepos and sub trees?
- fnord123 5y ago
  perforce helix core
- usrnm 5y ago
  Perforce?
- im_down_w_otp 5y ago
  Probably the most popular one would be the "new hotness" that everyone used, or aspired to use, before git became popular, Subversion (https://subversion.apache.org/ https://subversion.apache.org/). There are others that aren't free (e.g. Perforce) and some that aren't quite dedicated to the monorepos & subtree workflow, but which handle it better by design (e.g. Darcs, http://darcs.net/ http://darcs.net/). But, mostly I'm thinking of Subversion.
  - 0xbadcafebee 5y ago
    The reason I would use a Git monorepo over Subversion is that Subversion is really painful to use. I would rather workarounds and kludges than that tire fire.
    - im_down_w_otp 5y ago
      That was never my experience with Subversion, but YMMV.
  - dalyons 5y ago
    haha yeah, noones going to go back to subversion. The sum of the pain of the SVN problems solved by git is much larger than the slight pain of using git for a mono-repo.
  - triceratops 5y ago
    Subversion on the server used with git-svn is bearable. Most of the advantages of git (local commits, rebasing, easy branching and merging) manifest themselves on the client-side. The problem with using svn on the server is the lack of good tooling for things like code review. There's no SvnHub or SvnLab.
- deleted 5y ago
  [deleted]
gedy 5y ago
A big chunk of the industry joining in past decade has never seen/used anything but git, so it's the one hammer they have available.
- quotemstr 5y ago
  Is that even a bad thing? If people are familiar with git --- its command syntax, its commit model, its collaboration setup --- why not let them keep using this model? Isn't it better for everyone if we put a few hundred people on targeted scalability fixes for git instead of making a few million people drop productive work and learn a new tool? I mean, most of the people in industry today have known no character encoding except ASCII and its supersets --- and that's a good thing!
  - Uberphallus 5y ago
    Git, while better now, it still allows people who are just familiar to shoot themselves in the foot.
    - quotemstr 5y ago
      So? It's the standard. Anything else starts with -1000 points. Something like hg might be better, but not better enough to be worth the cost of breaking uniformity in the industry.
    - prionassembly 5y ago
      I never get the footgun argument. If you need a gun, you're liable to shoot yourself. Programming in general is more and more accessible to wider audiences, but it hasn't become intrinsically easier.
- deleted 5y ago
  [deleted]
ot 5y ago
The problem is that the alternatives are much, much worse. There's nothing about the git/mercurial object models that makes them intrinsically inefficient with monorepos. What's inefficient is materializing the object database (when cloning) and the working copy (when checking out), when you're only going to need tiny portions of them. Subversion doesn't have the first problem (but comes with extremely slow history operations), but sparse checkouts don't really solve the second because you have to statically know what to filter. A better direction is instead to virtualize the filesystem, so you get the semantics of a real monorepo with git/mercurial, and you fetch only what's actually needed without any change to your tooling (it just needs to interact with the filesystem). It's also very easy to transparently implement caching and prefetching this way. This is the approach that Facebook and Microsoft took, and I believe Google too.
- WorldMaker 5y ago
  Though it is interesting that Microsoft's own efforts have been moving away from the virtual filesystem approach and back towards making sparse checkouts better/more reliable and better/more reliable support for partial checkouts (of history especially) and better memoization and caching of history reachability information (git commit-graph).
jayd16 5y ago
No other DVCS is as popular. Git has a vast ecosystem of tools. No one wants to drop that. Its certainly not against the design goals as official tooling supports shallow and sparse checkouts, they're just experimental features. We should just strive forward and continue to make these features good.
an_opabinia 5y ago
> It forces you to actively work against git's design goals and implementation. It works against GitHub's design goals. You could work on multiple, logically distinct projects in the same git repository easily, if you so choose. git was designed for Linux's workflow.
SquishyPanda23 5y ago
> What I don't understand is why people are using git for this kind of workflow. People like to use distributed workflows even with monorepos. E.g. chains of commits, branches, rewriting local history, etc. It's clear that people want a mixture of monorepos with distributed workflows. There are two ways to get there: add distributed flows to a monorepos, or build a monorepo layer over a distributed tool. Both seem like valid approaches. The market will decide which approach it prefers.
deleted 5y ago
[deleted]
TheNewAndy 5y ago
Isn't git designed around the linux kernel repository, which is a monorepo? I get the impression that things like LFS, submodule and subtree are hacks added onto git to try to make it behave like something it isn't.

endisneigh 5y ago

What are these tools designed for monorepos and sub trees?

fnord123 5y ago
perforce helix core
usrnm 5y ago
Perforce?
im_down_w_otp 5y ago
Probably the most popular one would be the "new hotness" that everyone used, or aspired to use, before git became popular, Subversion (https://subversion.apache.org/ https://subversion.apache.org/). There are others that aren't free (e.g. Perforce) and some that aren't quite dedicated to the monorepos & subtree workflow, but which handle it better by design (e.g. Darcs, http://darcs.net/ http://darcs.net/). But, mostly I'm thinking of Subversion.
- 0xbadcafebee 5y ago
  The reason I would use a Git monorepo over Subversion is that Subversion is really painful to use. I would rather workarounds and kludges than that tire fire.
  - im_down_w_otp 5y ago
    That was never my experience with Subversion, but YMMV.
- dalyons 5y ago
  haha yeah, noones going to go back to subversion. The sum of the pain of the SVN problems solved by git is much larger than the slight pain of using git for a mono-repo.
- triceratops 5y ago
  Subversion on the server used with git-svn is bearable. Most of the advantages of git (local commits, rebasing, easy branching and merging) manifest themselves on the client-side. The problem with using svn on the server is the lack of good tooling for things like code review. There's no SvnHub or SvnLab.
deleted 5y ago
[deleted]

gedy 5y ago

A big chunk of the industry joining in past decade has never seen/used anything but git, so it's the one hammer they have available.

quotemstr 5y ago
Is that even a bad thing? If people are familiar with git --- its command syntax, its commit model, its collaboration setup --- why not let them keep using this model? Isn't it better for everyone if we put a few hundred people on targeted scalability fixes for git instead of making a few million people drop productive work and learn a new tool? I mean, most of the people in industry today have known no character encoding except ASCII and its supersets --- and that's a good thing!
- Uberphallus 5y ago
  Git, while better now, it still allows people who are just familiar to shoot themselves in the foot.
  - quotemstr 5y ago
    So? It's the standard. Anything else starts with -1000 points. Something like hg might be better, but not better enough to be worth the cost of breaking uniformity in the industry.
  - prionassembly 5y ago
    I never get the footgun argument. If you need a gun, you're liable to shoot yourself. Programming in general is more and more accessible to wider audiences, but it hasn't become intrinsically easier.
deleted 5y ago
[deleted]

ot 5y ago

The problem is that the alternatives are much, much worse. There's nothing about the git/mercurial object models that makes them intrinsically inefficient with monorepos. What's inefficient is materializing the object database (when cloning) and the working copy (when checking out), when you're only going to need tiny portions of them. Subversion doesn't have the first problem (but comes with extremely slow history operations), but sparse checkouts don't really solve the second because you have to statically know what to filter. A better direction is instead to virtualize the filesystem, so you get the semantics of a real monorepo with git/mercurial, and you fetch only what's actually needed without any change to your tooling (it just needs to interact with the filesystem). It's also very easy to transparently implement caching and prefetching this way. This is the approach that Facebook and Microsoft took, and I believe Google too.

WorldMaker 5y ago
Though it is interesting that Microsoft's own efforts have been moving away from the virtual filesystem approach and back towards making sparse checkouts better/more reliable and better/more reliable support for partial checkouts (of history especially) and better memoization and caching of history reachability information (git commit-graph).

jayd16 5y ago

No other DVCS is as popular. Git has a vast ecosystem of tools. No one wants to drop that. Its certainly not against the design goals as official tooling supports shallow and sparse checkouts, they're just experimental features. We should just strive forward and continue to make these features good.

an_opabinia 5y ago

> It forces you to actively work against git's design goals and implementation. It works against GitHub's design goals. You could work on multiple, logically distinct projects in the same git repository easily, if you so choose. git was designed for Linux's workflow.

SquishyPanda23 5y ago

> What I don't understand is why people are using git for this kind of workflow. People like to use distributed workflows even with monorepos. E.g. chains of commits, branches, rewriting local history, etc. It's clear that people want a mixture of monorepos with distributed workflows. There are two ways to get there: add distributed flows to a monorepos, or build a monorepo layer over a distributed tool. Both seem like valid approaches. The market will decide which approach it prefers.

deleted 5y ago

[deleted]

TheNewAndy 5y ago

Isn't git designed around the linux kernel repository, which is a monorepo? I get the impression that things like LFS, submodule and subtree are hacks added onto git to try to make it behave like something it isn't.