[slaymaker1907]

Is rewriting the history for large repos really that difficult besides coordinating with other contributors? My understanding is that it shouldn't be that much worse than "git gc --aggressive". Yes it is expensive, but it is the sort of thing you can schedule to do overnight or on a weekend.

[sjansen]

The issue is breaking external references.

Do you include git SHAs in your bug tracking system? Or perhaps your department wiki links to a specific commit to document lessons learned? Maybe you're using Sentry and find including the git SHA of the build to be invaluable for troubleshooting?

For some organizations, rewriting history would be a non-event and for others it would be a major disruption.

[cookiecaper]

Yeah, git is really not a mature or well-designed VCS. The fact that you can trivially lose the supposed permanent reference -- and that it's encouraged as part of several common workflows at that -- should be more than enough to demonstrate this. If you care about history, use a VCS like Fossil.

[inimino]

What is encouraged by Github is not always exactly the same as what is encouraged by the maintainers of git.

[cerved]

the SHA is permanent, you're responsible for backup

[alkonaut]

The problem I see is that things like commit hashes which are etched in history in bug reports, version tags etc, instantly lose meaning. Whether or not that’s a problem depends on how much of that you have.

[cerved]

git gc doesn't rewrite history, it packs objects in your local repertory into a pack file