Hacker News Reader

Comment by mooreds | Hacker News Reader

Would git prune ( https://git-scm.com/docs/git-prune ) help here? Or is the entire repo of reachable objects more then 2GB?

View on HN

Considering this from the thread, as a response from GitHub to their repack request:

> As it turns out, we only run repacks on a repository network level, which means that repacks need to consider objects from all forks of a given repository.

> Repacking entire repository networks will always lead to less optimal pack sizes compared to repacking just objects from a single fork. For GitHub, disk space is not the only thing we optimize for, but also performance across forks and client performance.

Repacking the repo locally more than halves the size:

> I tried locally right now to run git repack -a -d -f --depth=250 --window=250 and the size of the .git folder went from 2417MB to 943MB…

But GitHub repacking the repo network reduces the size by only 20%. So presumably GitHub can't aggressively remove things from a repo without affecting how forks work.

This blog post is very old (2015) but there's a section that describes their use of Git alternates to facilitate forks: https://github.blog/2015-09-22-counting-objects/#your-very-o...

The latter. It's >20 years of history, and if you want a straw test as to whether the history is relevant: I personally needed to look at >20-year-old history this winter.

Why did you need to look at >20 year old history?

A lot of big applications have features that are coded and go years with minimal changes.

My applications definitely have modules that only get touched when we do a major UI refresh (about once every 10 years.)

Not OP, but I've worked on lots of 20-50 year old CNC machines, and have done controls for press brakes and resistance welders that are more than 100 years in age (granted, the PLCs and PCs were added later to streamline the relay logic created around World War 1, but the cast iron and motion works date to that era). Two weeks ago I fixed up an RS232 DNC pipeline for a 1985 mill, the source code manuals were heavily yellowed but I eventually figured out the now-esoteric RS232 configuration. One of my coworkers worked on this equipment a bit more than a decade ago, but the newest part - a Windows 7 PC - was the first thing to break.

The addage "if it ain't broke, don't fix it" comes with the corollary that if you build it right it won't break...until it does. And then someone has to do some archaeology to get a process back online that hasn't been documented since dot-matrix printers and typewriters, much less git development. I'm also building stuff and making decisions today for machines that have 10, 20, or 30-year expected lifetimes, and the core components should last indefinitely as long as maintenance is performed.

Many businesses aren't built for and aren't compatible with a 2- or 3-year obsolescence cycle.

Because code written >20 years ago still runs today. I wanted to understand some odd behaviour, ran git blame to find the relevant commits, then looked at the commit messages. Some of the lines involved were old.

Reply on news.ycombinator.com