3 ms·

Our codebase is around 20 years old and was in CVS, then SVN, then git. Then several years after git, a new git repo without any history due to poor use of the

Our codebase is around 20 years old and was in CVS, then SVN, then git. 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). In all the steps we preserved the commit history, except for the final git->git. However also when we moved from SVN to git we kept the old svn server running as a historical archive for several years, as we didn’t carry across all projects (some were already EOL’d years ago). During that time I looked at it maybe twice, and ultimately we decommissioned it. Likewise with the new/old git repos, we still have the old git repo if we need the history. One final thought: git blame was nice, until someone reformatted the entire codebase and committed it back in (we’ve since adopted better git workflow and code review practices!)

ptsneves 7y ago
You can use git log -S and the regex of the line to see how that line changed over time. It is also called git pickaxe. Also git diff has an ignore white space which basically ignores formatting stuff if that is the case. I believe that git log has it also.
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 ago
  Thought about it, but for external security audit purposes we aren’t allowed to rewrite history.
  - carlmr 7y ago
    Rewriting 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.
hinkley 7y ago
You should have rewritten history. It’s less invasive than doing it in svn.
testplzignore 7y ago
> git blame was nice, until someone reformatted the entire codebase We have a few "blame walls" in our codebase like this due to formatting changes or badly-implemented restructuring/renames. When I'm in bitbucket tracing back through the history of a particular line, I end up having to manually jump back a few commits at certain points in time, and then if the file was renamed I have to also navigate to its old location/name.

ptsneves 7y ago

You can use git log -S and the regex of the line to see how that line changed over time. It is also called git pickaxe. Also git diff has an ignore white space which basically ignores formatting stuff if that is the case. I believe that git log has it also.

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 ago
Thought about it, but for external security audit purposes we aren’t allowed to rewrite history.
- carlmr 7y ago
  Rewriting 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.

hinkley 7y ago

You should have rewritten history. It’s less invasive than doing it in svn.

testplzignore 7y ago

> git blame was nice, until someone reformatted the entire codebase We have a few "blame walls" in our codebase like this due to formatting changes or badly-implemented restructuring/renames. When I'm in bitbucket tracing back through the history of a particular line, I end up having to manually jump back a few commits at certain points in time, and then if the file was renamed I have to also navigate to its old location/name.