You could in principal store the old history in a separate repository then (reasons for this may be that the repo historically contained many binary files, possibly because it’s been converted from an SVN repo). After refactoring and rebasing (Note: You do in fact change the SHAs in this scenario – what they do in the blog post is a rebase+squash/fixup basically.) you prepare a new repo which is much smaller and in which you do all further development.
However, sometimes it may be necessary for developers to do a `git blame` which needs to include the old data or similar. If this happens, you add the historical repo as another remote and `git replace` the oldest commit from the dev repo with the historical repo.
Only a few developers will ever need to use `git replace` in this scenario, so it would not say that it is too confusing. (If it was confusing, I’d say everybody would probably have learned that it exists the hard way…) Maybe think of it as a kind of git submodule but for time.
However, sometimes it may be necessary for developers to do a `git blame` which needs to include the old data or similar. If this happens, you add the historical repo as another remote and `git replace` the oldest commit from the dev repo with the historical repo.
Only a few developers will ever need to use `git replace` in this scenario, so it would not say that it is too confusing. (If it was confusing, I’d say everybody would probably have learned that it exists the hard way…) Maybe think of it as a kind of git submodule but for time.