> Improving repository maintenance

There's one thing I'd really like to see there: the ability to lock out the repository and perform a really aggressive repack. I'm talking `-AdF --window=500` or somesuch. On $dayjob's repository, the base checkout is several gigs. Aggressively repacking it reduces its size by 60%.

There's also a git-level thing which would greatly benefit large repositories: for packs to be easier to craft and more reliably kept, so it's easier to e.g. segregate assets into packs and not bother compressing that, or segregate l10n files separately from the code and run a more expensive compression scheme on that.

> On $dayjob's repository, the base checkout is several gigs.

Why is it several gigs? Is that really necessary?

> Why is it several gigs?

A lot of code written by a lot of engineers over a lot of years.

I'm not sure what other answer you're expecting?

I work with a compiler that has just tens of engineers working on it over just a decade or so and even that's a 6 GB repository. No binary assets. Just source code and configuration I think. I really don't think it's that unusual.

> Is that really necessary?

What would you do? Delete history every year or so? I regularly annotate files and see useful history from ten years ago that I need to do my work.

> I'm not sure what other answer you're expecting?

I've seen some things. Binaries, large files, isos, generally just any large file with no lines that somebody just didn't know better and committed, changed a few bytes a few times, and generated huge deltas quickly.

I'm far more surprised you don't know what he was expecting than I am that he asked, considering how many times I've run into this in the past.

https://github.com/oracle/graal

It's not even a mono-repo - this is just part of the project.

Maybe someone's got some tools that let them dig around in the history and find large things or explain why it's so large? I don't think they've been checking ISOs in.