I am working in a fairly old code base. In the code base they have the classic source control, gigantic code blocks at the top of the files and above the function definitions that have something like date, name, and what they changed.

I wanted to start refactoring the code and remove these blocks but not lose the history information. Is there a decent strategy to do this?

Some of these comments go back almost 20 years, and stopped once the main developers switched to CVS and then later git. So not even sure how useful the comments are, but wouldnt want to lose them just in case.

I was thinking of making a git branch, removing all the comment blocks, and then merge branch into master. Any better suggestions?

  • 1
    What do you mean by "not lose the history information"? Do you mean that you must be able to find it back in the repository or should it also still be visible in the current revision of the files? Mar 1, 2019 at 7:31

2 Answers 2

  1. You should create a "special" baseline in CVS, marked properly that it is a snapshot before (major) refactoring.

  2. After that, you do all the refactoring that you want.

  3. At the end, when you are satisfied with the results, you repeat step 1 - and specify that this is "new" code after refactoring.

The purpose of the snapshots / baselines is to be able to "undo" the refactoring, in case that something is found to be wrong.

NOTE: You should get the green light for this from whoever has responsibility for the project - project manager, your boss, architect, team...


What I would have done at the very beginning of the project is to create "fake" commits of the very first version that was imported into CVS using the datestamps for the commit date and the comments as the commit message. That way, you get all those commit messages with the correct dates. You do not get the correct source corresponding to that message, but you do not have that today anyway. Those versions are lost.

Unfortunately, it is now too late for that, unless you want to rewrite the entire history of the Git repository. I only mention it for the benefit of readers who come to this question at an earlier point.

However, you can still do the same thing in a separate repository and use the "graft" feature of Git to graft this repository's history onto your real one. This is for example used to create the "historical" Linux repository, and was in fact created for this purpose. Linus himself deliberately started his own repository only at the time he wrote Git and did not import any history. However, other people then created repositories where they imported the entire Bitkeeper history as well as the entire history before that (by importing every tarball of every historical release they could find and using the release email as the commit message).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.