1. understand what IS the bloat So what is the bloat? I used a script that could remove a file from the whole history. But I'm not sure if it's what you want.

One way is to run maintenance on it regularly

It'll setup a cron for you as well

changing git history is probably off the table. Understanding what the bloat is is my first goal. A function that let's me list the biggest objects or something is probably useful. I wonder if there is much damage with big objects that are "old" in the history though. Maybe they don't impact performance because it doesn't need to pack them or sth to begin with?

@U028ART884X if you have your script at hand, I'm interested in trying it out

I think I was rewriting history. I don't remember and I did it only once. I think it could be something like here, but well.. they rewrite history. https://stackoverflow.com/questions/43762338/how-to-remove-file-from-git-history

To keep it lean you might consider a rebase workflow instead of a merge workflow. It requires more consideration but allows you to keep a branch free of ad-hoc quasi pollution.

something that's worked great for me is to do all new work on a local-only feature / bugfix branch, then rebase the commit history so it tells the story of how the change was implemented in a clean way before merging onto master (this avoids the mess and confusion of rewriting the history of a shared branch)

> How to cleanup a bloated git repo and what are the best practices that keep it lean? Unless you rewrite history and purge objects from the time they were introduced, they will always persist in the repository. Typically the problem people actually want to address is slow clones in build pipelines or some such thing. Is that what you are facing? Or something similar?

brainstorming here: a simple gordian knot style solution would be to remove the git data from the directory and make a new repo, archive the old project and start a new repo with 0 history in the working repo - if you need history before the purge you can find it in the old repo

that's simpler and less error prone than a massive rewrite of history that's already in the main brainch

@U051MHSEK yea the pack size really is more a side quest. Just performance of git commands are the important thing. @U051SS2EU yea really sounds like it's a fix

Right, because with any sort of git-like immutable accrete-only storage, there is only one sensible answer to this question... > what are the best practices that keep it lean? Don't add bloat in the first place! (And maybe the other one is to say "enough" once it gets big enough. Because unchecked, all such storage will converge to a bloatchain that needs the power supply of a small country for every addition.)

In summary: “Not much, really”

...except for, and to quote ... and over a thousand bug fixes. that may potentially affect lots of people...

The Java doc link to compiling code sounds interesting

> ...except for, and to quote ... and over a thousand bug fixes. that may potentially affect lots of people... I’d expect that those will get backported to the LTS, no?

That would be nice indeed. Although, I tend just to roll with the latest whenever it comes out.

There are tens, if not hundreds, of articles online that review and compare different backup options - from "build your own" to SaaS.

Indeed, it sounds like the term you're looking for is "backup". Your best choice is online search, here are some keywords that you can use to get better results: • backup (obviously) • software • the name of your OS (e.g. windows, macos, linux, etc) • open source (this is optional but I highly recommend it) perhaps more importantly, it's a good idea to enhance your search-fu, if you don't feel comfortable with it. Here are a couple guides I found: • https://www.wikihow.com/Search-the-Internet • https://www.lifewire.com/web-search-tricks-to-know-4046148

For instance, with the query site: open-source backup software windows you'll get these pages: • https://reddit.com/r/freesoftware/comments/rog7vl/what_free_and_open_source_backup_software_do_you/ • https://reddit.com/r/opensource/comments/3j0607/open_source_backup_recommendations/ This way you'll get lots of recommendations that you can try out and see for yourself which one is the best for you 🙂

Same... I thoroughly enjoyed reading this book! (Apparently, the later editions are watered down / diverge from the author's original intent. At least that's what the Internet says.)