Depending on use case, anything from weekly to very occasionally, but in all these cases it's invaluable. E.g., selectively reverting commits that are known to

Depending on use case, anything from weekly to very occasionally, but in all these cases it's invaluable. E.g., selectively reverting commits that are known to have caused bugs, checking something whilst preparing release notes, working out how we did X in the past, etc. > At my current company they place a huge value on that history, so much so that they haven't transitioned from SVN to git solely because of the logistical challenge of migrating 30 years of commits. I assume they've actually tried to do it? I ask because there's a bunch of tooling and at least one reasonably well understood process for achieving this and preserving history so it's pretty low investment to try it out and see if it works. Here's Atlassian's version, for example: https://www.atlassian.com/git/tutorials/migrating-overview https://www.atlassian.com/git/tutorials/migrating-overview (I will grant you that figuring out how to navigate to the next page of the current tutorial at the bottom of the page is unnecessarily complex.) I suspect with 30 years of history it's going to take a very long time to do the conversion (days to weeks), but you can set it off and leave it running. Once you have your initial migrate done you can set up syncing to git, and then you need to pick a time when everyone will stop committing to svn, allow a sync and verification window of a few days, and then everyone starts using git. It gets more complex with multiple projects ongoing, and scheduling around releases, but making this happen is more a matter of will than battling complexity.