immutable commit messages, why?
Stuart McGraw
smcg4191 at frii.com
Wed Mar 19 13:33:20 CDT 2008
The "obliterate functionality" thread prompts me to post a somewhat related question I have wanted to ask for a while...
Why are commit messages immutable? They are (in theory) not really part of the state of a set of files but rather meta-information about that state, yes?
This issue is preventing my adoption of a DVCS. I have a CVS repository in which a number of commit message are wrong, misleading, vague, or otherwise sub-par. I not infrequently need to find previous work based on these messages. As I find problems or have time, I fix bad commit messages by editing the CVS repo files in-place. But once I import this repo into Mercurial (or any other free DVCS AFAIK [1]) the commit messages will be set in stone for all eternity, so I have put off making the jump.
I suspect the real reason commit messages are revision controlled is that DVCS' have a hammer for managing immutable revisions and it was more expedient (and seemed cool) to shape commit messages into the form of a revision nail, than to invent a whole separate mechanism for managing them. And that poor commit messages aren't a show-stopper problem for most users so they are simply lived with.
I can imagine a DVCS where the commit message do not participate in the revision hashes and have a timestamp or independent hash. When a merge having changesets with differing commit messages is done, the merger would be asked (or a configured policy consulted) to determine which to accept.
While it would involve some significant reengineering of Mercurial to do something like this, are there any reasons doing so would be a bad idea?
----
[1] T believe the commercial product AccuRev has non-immutable commit messages and considers it a feature.
More information about the Mercurial
mailing list