immutable commit messages, why?

Stuart McGraw smcg4191 at frii.com
Wed Mar 19 19:59:50 CDT 2008


Dustin Sallings wrote:
> On Mar 19, 2008, at 11:33, Stuart McGraw wrote:
>> 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.
> 
> Your description also sounds like it applies to the code itself, or 
> comments within the code, or the changeset author, or the date.
> 
> It's all the same to me.

It doesn't seem the same to me.  It seems to me that the importance 
of the integrity of commit messages is fundamentally lower than that 
of files.  

After all, regardless of what a commit message says, one can look 
at the actual differences between the revision and its parent.  And 
if you have information that really needs to be revisioned, you have 
the option of putting it in a revision controlled file.

One could of course revision the commit messages (and I think some 
VCS' do that by having revisioned properties and using properties 
to store commit messages?) but I wonder if that isn't overkill in 
99% of real-world use cases.  I would include changeset-author in 
the set of non-revision controlled meta-info.  Is there really 
significant value in enforcing the immutabilty of an obsolete email 
address in a repository, rather than letting the author update it 
to his new address before changing jobs?  (Yes, some evil-doer could 
change the address to me at evildoers.com, but is that a serious problem 
given the change is not silently accepted and propagated, and that 
this again, is meta-information that does not affect the integrity 
of the code?)

Commit messages are also not like code changes in that committing 
a new revision *is* the way of making code corrections.  That 
there is no such way to correct a commit message is evidence of 
such messages' fundamentally different nature.




More information about the Mercurial mailing list