RCR collateral is causing repo bloat

[nickswalker]

We have about 100MB of posters in the repo, a little more than half the repo's size. There's plenty of room left to grow, but the heft already makes clones and deployments slow. Now that we have some other assets to track as well (LRR art, new logo art), it's a good time to think about setting up another repo for these, and to consider scrubbing them from this repo. This means rewriting the repo's history, so something to look at in the offseason.

[emichael]

I think this just complicates things, and I'm not actually sure what problem it solves. Deployments take a few seconds, but who cares? And we'd all keep local clones of both repos, anyways. I'd much rather have everything in one place and being served under the same domain.

[nickswalker]

10-15 seconds to clone a repo on a fast connection is silly for a tiny static site, especially if it's mostly spent copying and unpacking bits that no site-viewer sees, but I agree; it's minor and there's a convenience/complication factor to weigh. Here's my accounting:

• Keeping the files in the site repo provides me no convenience because I do not edit or view these files. Browsing the history, they've been write-once, so no one edits them, and they're not linked from the site so close to no one views them. While you may want to keep a local clone of 100MB+ of non-site assets, I do not. With a separate repo, keeping a local copy becomes opt in and I'm thinking you can count the number of people who would opt in on one finger 😛 .
• The additional complication is a one-bit policy; design originals and assets go into a separate repo, everything else goes here. An equivalent policy today is "things that go on the site, go in the site repo". Also, I'd have to run bfg once to fix things historically and folks would need a fresh clone after.

My calculation is it's worthwhile, but perhaps others have different weights on these things.

[emichael]

Who is cloning it, though? And how often? Disks are cheap.

I don't like breaking up a tiny, simple site into multiple repos that need to be served from different places. (Not sure exactly how GH pages handles it, but I'm pretty sure we'd end up having to serve those from something like assets.raceconditionrunning.com.) It's an anti-pattern that I always find annoying. And the worst aspect from a usability standpoint is yet another quirk of the infra that someone has to learn when they start interacting with the repo.

You know you can do a sparse clone right? It's pretty simple, no need to make everyone opt in.

[emichael]

Something like

git clone --filter=blob:limit=3m --sparse git@github.com:raceconditionrunning/raceconditionrunning.github.io.git
cd raceconditionrunning.github.io
echo '/*\n!/posters\n!/img' > .git/info/sparse-checkout
git checkout HEAD

[nickswalker]

I'm not suggesting taking away anything that we serve on the site; I'm suggesting that we take design files (.pages, .pdf, .ai once I add LRR stuff) and put it in a separate repo. It also happens that these things already make up half the mass of the repo, which is silly because they have nothing to do with the site. No one will ever need to use the other repo unless they are making a t-shirt, printing a poster, or designing new medals.