I love how the first real slide goes straight into the fake manpage generator: <a href="https://git-man-page-generator.lokaltog.net/" rel="nofollow">https://git-man-page-generator.lokaltog.net/</a><p>"App Repo Size Issues:" yes, this is the Achilles heel. By being a full distributed system where every client has to carry a full copy of the history of everything, some common practices become unsustainable. I've had two employers that checked build artefacts into SVN, for example: do that with git and the repo becomes unusably large very quickly. Vendoring dependencies, a useful practice if your project is slow-moving, will also bloat the repo. They should be using "shallow clone" for Jenkins, but even that can be surprisingly large.<p>I've also been through the "apply BFG to repo" phase (very time-consuming, and blocks all commits while you're doing it!)<p>> New idea: run the formatter against every commit in the history, so that it looked as if the code was "always formatted the right way".<p>This is actually brilliant, for the reason they give - keeping "credit" assigned correctly to original commits.<p>> Determined it was okay if older commits were potentially "broken", as long as the latest commit runs and has all of our changes as of late 2018<p>I'm less OK with this, as the chances of an automatically introduced horrible bug which you can't trace seem rather high <i>and</i> you've wrecked any chance of using git-bisect! But if the "tip" is the only supported released version, I suppose it's less critical.<p>It's also interesting that most of the speed issues are addressed by re-architecting to avoid syncing to disk. If there was an easy Windows RAMdisk this might have made almost as much of a difference.