[smilingsun]

From the article:

> The GitHub.com repository is almost 13 GB on disk; simply cloning the repository takes 20 minutes.

Their problem seems to be mainly this. Which I'm surprised that they don't fix, but invent a workaround for. Deleting/rewriting a git repo's history is not impossible and often necessary for these kinds of cases.

[koyote]

How often do you clone a repo?

Our monorepo is multiples of that and the last time I cloned it was 2 years ago. When we first moved to git we simply had a 'clean' clone sitting on a network drive that all users could just copy to their machines to get started.

[ghthor]

I previously worked at a company on the team that managed the monorepo and the build system for the code within it. Our checkouts were 4.5GBS full. We had discussed performing yearly rollups, likely around Christmas for the current version. This would essentially be take a full checkout and `rm -rf .git && git init && git add --all` starting out with a new genesis commit. We'd keep the old "branches" in a separate archive only repository on our github and force push this new main copy to the working repository. And then provide guides and support for engineers to utilize the new rolled up repo and port any of their existing WIP.

The concerns were long lived branches that had WIP and I think also just misunderstandings about what was going to happen. We never did it.