Refactoring large comment blocks

Question

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?

Answer 1

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...

Answer 2

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).