Hacker News Reader

Comment by chrisseaton | Hacker News Reader

> 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.

View on HN

> 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.

If people want a concrete example, here's a 6 GB repo that's 90% Java, 5% C, then some other languages.

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.

I'm totally not surprised that large repos exist, without having fallen prey to any antipatterns. Just saying that I know "have you committed any binaries, dependencies, generated code, etc" are the first questions I tend to ask when somebody tells me their repo is massive. In part selection bias, though, because usually the people working on super old projects know exactly why.

https://rtyley.github.io/bfg-repo-cleaner/

I was really taken aback by this given my previous experience with the Linux kernel git repo size. So, I just checked out Graal.

Receiving objects: 100% (981372/981372), 187.08 MiB | 6.39 MiB/s, done.

% du -sh graal 328M graal

% du -sh .git 221M .git

And that includes many binary files that were added and removed over time, but not filter-branched out of existence, including jars, pngs, pdfs :)

(https://stackoverflow.com/questions/10622179/how-to-find-ide...)

Huh... maybe I have a degenerate copy for having it so long and I should try running the compression commands myself.

See also “git prune” to remove references to branches and objects no longer on the remote server. Check the docs though I think in some cases I might delete local branches or objects so make a backup first.

git filter repo has tools for analyzing history

Nope, the answer is exactly what’s above, this is a large and old project with a fair amount of churn. There are assets in there but they’re a small minority of the issue.

The biggest issue is actually the l10n stuff. It’s all text with lines but there is a lot of it and historically the exports were not really ordered so every major update to the translation files scrambled everything.

> 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.

That's a lot of code! I think that is at least a little unusual. The monorepos I see are usually large because people gratuitously commit large binary files (and sometimes change them, generating huge changesets).

It is. Let's say we are talking 30 person-years, that is 60000 days. It means 100KB of text written per day and engineer.

Can't edit anymore, but ofc the math is off by factor 10: 'tens of engineers over more than a decade' is more in the realm of 300 person-years. Still 10KB per day and engineer, which is maybe 200-500 lines of code. Far above average still, but approaching something realistic. This is if we are talking 6GB with full history and without any compression.

That just seems an excessive amount of text! But the Linux kernel repo (.git + working copy) is over 7GB.

It turns out folks can write an ungodly amount of code.

but you have to write ungodly amounts of code to get a repo that big, and it's not even that big

that or check-in binaries, logs, database backups or other things that don't belong in VC. TBH it's pretty much always this

Reply on news.ycombinator.com