immutable commit messages, why?

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


Matt Mackall wrote:
> On Wed, 2008-03-19 at 12:33 -0600, Stuart McGraw wrote:
>> Why are commit messages immutable?  They are (in theory) a critical
>> part of the state of a set of files and not just meta-information
>> about that state, yes?  

Fortunately, my email client works like I summit a DVCS 
could, and I when I read your response, I got a notice 
that said:

Notice: quote changed:
Matt Mackall:
+ They are (in theory) a critical
+ part of the state of a set of files and not just meta-information
Stuart McGraw:
- They are (in theory) not really 
- part of the state of a set of files but rather meta-information 

but since I my email is configured to trust quote changes 
from you, my email repo now has your changed quote and I 
just have a log file message documenting the change.  
Luckily, since quotes are not immutable like code, I have 
changed it back and have removed you from my list of people 
I trust to change quotes automatically. :-)

> That, and we can't trust people not to go and change our messages on us
> in interesting ways. If we let people change changelogs, we'd then need
> an immutable history of -those- changes. What a nuisance.
> 
> [Stuart didn't actually write that quoted bit, of course.]

But do changes to commit messages rise to the same level of
importance as changes to the code?  Regardless of how the
commit message summarizes a changeset, you *can* confirm
it with assurance by examining the changeset diff. 

And obviously such commit message changes would not be 
silently and unquestioningly accepted.  If you have 
information related to a revision that needs to be revision-
controlled, you still have the option of putting it in 
a revision-controlled file.

Against this (I think small) risk of nefarious commit 
message changes, you have actual, known bad, commit messages:
ones that fails to mention major changes in functionality,
one with serious typo's like leaving out the word "not", and 
an annoying background noise level of misspellings, obsolete
email addresses and url's, etc.

I believe some VCS' have versioned properties and store commit
messages in such properties.  I guess that is a way of dealing
with the issue but I wonder if it isn't overkill in 99% of 
real-world uses.

But however it is done, I think a strong argument can be made
that any system that allows the input of information by humans
but fails to provide a way to correct that information, is 
fundamentally broken.  (I think some people claim that argument 
applies to the U.S. anit-terrorist list. :-)


More information about the Mercurial mailing list