immutable commit messages, why?

[Martin Geisler]

Stuart McGraw <smcg4191 at frii.com> writes:

> 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 think it *is* cool to make all the meta data be part of the commit.
Given one changeset hash (which I trust) I know that every commit
message is trustworthy.

> 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.

Could you not just make a Wiki where you export all commit messages once
and then update them as you find errors? Then you would have your
free-floating commit messages along side your normal commits.

-- 
Martin Geisler

VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
SMPC (Secure Multi-Party Computation) to Python. See: http://viff.dk/.