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