4 ms·
I started working on a codebase where the git repo is 56gb. Turns out that it's a bunch of binary files that were committed and updated a buncha times more than
by charles_f 3y ago
I started working on a codebase where the git repo is 56gb. Turns out that it's a bunch of binary files that were committed and updated a buncha times more than 2y ago. They're not even in the main branch anymore. Nobody in the main team working on that seem to have cared enough to fix it before.
Don't underestimate the power of complacency
- DistractionRect 3y agoIt's kinda careless to rewrite history just because a repo is large. Any reason you aren't doing a partial/shallow clone?
- charles_f 3y agoWhy though? I understand the point of keeping some history, but what's the point of keeping individual commits from years ago? It's not as if you'd cherry pick anything from back then. And then, you can still keep a full version of the history in another repo if you really have auditing requirements that mandate keeping history forever.
- DistractionRect 3y ago> what's the point of keeping individual commits from years ago? It's not as if you'd cherry pick anything from back then. If you extend the logic, what's the point of keeping any commits from years ago? What's a good cut off date to just start discarding history? Rewriting it? But in the same breath, what's the point of cloning commits from years ago? It's not as if you'd cherry pick anything from back then. And that's my point, the former requires an org decision and active action, and the other is a blobless clone. The nice thing about the blobless clone is you can always change your mind, you can get old blobs if you find you need it. But if you threw out old commits, and you need them later... that's the brakes.