It costs almost nothing to use the commit history maintained by the version control system. However, during a major project refactoring (or reorganization / cleanup) effort, functions and classes and even namespaces will be moved around; sometimes several files will be merged together and other files will be split. These changes often lead to the loss of the original commit history of a few files.
In my personal opinion, the up-keeping of the organization of the project is more important than keeping the source code history. Good project organization allows new features to be added continuously with reasonable effort, while the value of source code history appears to be dubious.
Furthermore, with the use of unit testing, regression issues are quickly identified. As long as the latest version continues to satisfy all of the software requirements, do we actually need to preserve the history of the source code?
I understand that any shipped source code must be preserved because of the need to provide support to the customers without requiring them to perform a major version upgrade. But aside from this, is there any value in keeping the history of source code commits?
Does source code commit history play any role in the communications between team members? What if we abolish the commit history, but instead rely on "source code" + "unit testing code" for communication?
Does the existence of commit history make one complacent about the long-term documentation of important information about the project, such as the major design/requirement changes and the streams of thought that drove those changes?
Best Answer
To use commit history for more than "made changes" or "fixed bug" type comments, it should be linked with your issue tracking system. Every change, every commit, should have some issue associated with it so you know what changed, by whom, and why.
Sufficiently complex software rarely has all requirements implemented and all bugs fixed for a multitude of reasons, so I think your assertion here is, let's say, optimistic.
Suppose you are on version 7.8 of your program. But you are supporting, in the field, 12 different active versions, like 1.6, 2.2, 2.8, and so on. Each of these aren't going to be upgraded to the latest version for a variety of reasons, so you are supporting all with bug fixes. A customer finds a bug in your latest 7.8 release. You fix it in 7.8. How do you know how many of the other releases need to be fixed? Without source history and issue tracking you don't.