Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
Still, with git it appears to me that it would be more complicated to fix a problem in the history, since if a commit is split in two or something like that then it's unavoidable that the hashes for all later commits change, right? Then everyone synching against it would have to migrate their local branches to the new repo, and hashes posted in email messages etc would no longer be usable either.
Well, let's put it this way, one proposed way forward would be the following:
a. Setup an official git repository somewhere (basically it involves copying my current tree to some place official). b. Turn on the git-cvs compatibility server for those still wanting to use CVS based tools. c. Declare the git repository to be official and turn the old CVS repositories into read-only archives for reference only. d. Start committing to the new git repository (either through git, preferred, or through the CVS emulation layer). e. In parallel we verify the correctness of the current history, and make amends where needed. No impact to the current operation. f. At some point in time, we declare history to be near perfect. At that time we archive the current repository, and refactor it entirely to get all the historical fixes in. g. Anyone having local branches which are based off of commits in the old git repository will have to rebase those branches onto the correct new hashes of the old commits (this actually is quite easy to do). h. Any old hashes mentioned in emails will only refer to the old git repository and are likely not to be found in the new one. i. Proceed with development as usual. j. If necessary, collect late fixes to history which have been forgotten, if deemed necessary, at some point in the future, repeat steps f through h to get the fixes in.
I've personally exercised all these steps myself in the past few months, several times, so did Martin, in order to keep up with my fixes. It's not difficult to do.