2 ms·
>Then several years after git, a new git repo without any history due to poor use of the first git repo (someone added binaries, bloated the repo to GBs instead
by carlmr 7y ago
>Then several years after git, a new git repo without any history due to poor use of the first git repo (someone added binaries, bloated the repo to GBs instead of maybe 200-300MB, which made git export horridly slow).
Considering you already needed to freeze work, couldn't you have removed/ammended the commits affecting those files and the force pushed including the history with a smaller repo?
- yardstick 7y agoThought about it, but for external security audit purposes we aren’t allowed to rewrite history.
- carlmr 7y agoRewriting history by squashing history in one new git repo with "initial commit" was bureaucratically acceptable I assume. Since working in a big company this is something I've been thinking about a lot. How a lot of traceability and quality enforcement often leads to lower traceability and lower quality. Quality enforcement at large often results in so much friction for changes that the company can't make necessary changes anymore and just piles on technical debt until it becomes unmaintainable. An example is the recertification process for airplane pilots that directly lead to "low friction" workaround like MCAS. After many iterations of this, modern 737s are now a pile of technical debt. The max was only the straw that broke the camel's back. With traceability like in your case you have the same. The "low friction" version is to throw away potentially pertinent historical information, because it wouldn't accurately reflect history. I don't have a solution for this, but it's been bothering me for a while.