4 ms·

GitHub isn't a monorepo because you can't change multiple projects with a single commit. In a monorepo you can do things like change a function signature and ch

GitHub isn't a monorepo because you can't change multiple projects with a single commit. In a monorepo you can do things like change a function signature and change all of its callers in one commit, without breaking anyone's build. If the implementation and its callers live in different projects within GitHub, then you can't do this safely, and you need to do more work to provide backward- and forward-compatibility in your changes.

CydeWeys 7y ago
This is very important. When you're developing a large monorepo like Google3 you frequently get large scale changes from engineers outside your team, doing exactly these kinds of large scale reactors. It puts the onus of fixing things on the people making changes in the widely used libraries rather than separately on all the individual library users, which is great. It's way more efficient to have one person who knows exactly what's changing go fix it everywhere than require dozens or more separate engineers to have to investigate some new incompatibility and then potentially resolve it in sub-optimal ways.
juiyout 7y ago
In your example (change a function signature and change all of its callers in one commit), would it require code reviews and approvals from every affected projects?
- alexhutcheson 7y ago
  Yes, although if you can prove convincingly that it's a 100% safe change you can often get approval from someone who has approval power for most of the repository. In practice, if you're changing 100+ individual callsites, then you would probably make a backwards-compatible change, then use an automated system to send out and manage a bunch of different commits to clean up call sites, then clean up your old function signature once all the commits are submitted. If your code isn't a really widely used library then you probably have fewer than 20 callsites, though, so it's nice to be able to do it in one commit.
- deleted 7y ago
  [deleted]

CydeWeys 7y ago

This is very important. When you're developing a large monorepo like Google3 you frequently get large scale changes from engineers outside your team, doing exactly these kinds of large scale reactors. It puts the onus of fixing things on the people making changes in the widely used libraries rather than separately on all the individual library users, which is great. It's way more efficient to have one person who knows exactly what's changing go fix it everywhere than require dozens or more separate engineers to have to investigate some new incompatibility and then potentially resolve it in sub-optimal ways.

juiyout 7y ago

In your example (change a function signature and change all of its callers in one commit), would it require code reviews and approvals from every affected projects?

alexhutcheson 7y ago
Yes, although if you can prove convincingly that it's a 100% safe change you can often get approval from someone who has approval power for most of the repository. In practice, if you're changing 100+ individual callsites, then you would probably make a backwards-compatible change, then use an automated system to send out and manage a bunch of different commits to clean up call sites, then clean up your old function signature once all the commits are submitted. If your code isn't a really widely used library then you probably have fewer than 20 callsites, though, so it's nice to be able to do it in one commit.
deleted 7y ago
[deleted]