immutable commit messages, why?

Martin Geisler mg at daimi.au.dk
Thu Mar 20 05:30:27 CDT 2008


Stuart McGraw <smcg4191 at frii.com> writes:

> Martin Geisler wrote:
>> 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.
>
> Do you know that? Even if your definition of trustworthy is that it
> hasn't been changed after it was commited, how do you know, when you
> accept a changeset from "me", that my machine wasn't compromised, etc.
> Whatever guaranties you have are provided outside of Mercurial, yes?

Yes, I was thinking of a digitally signed changeset. With that I have
the guarantee that someone used your private key at some point in time
to say "This changeset and its history are OK with me.".

I still /trust/ that you wont be signing random stuff and that you will
keep your computer secure, etc. But I think that is an inherent problem.

> And I would prefer a higher standard of trustworthiness: that a commit
> message accurately describes a changeset. Immutable commit messages
> are a barrier to achieving that.

Put that way, then I agree with you. Currently you cannot do a commit if
nothing has changed, but if that was allowed, then I could imagine that
empty commits would be a way to amend the commit messages:

  hg status
  M foo.c
  hg commit -m 'Fixed bug.'          # Bad commit message.
  hg commit -f -m 'Fixed bug 123.'   # Better message.

Here the second forced commit simply records another change message. The
tools that show commit messages could be taught to show the commit
messages of empty commits instead of the messages of parents. Something
like this:

  % hg log
  changeset:   1:ebcc4c481119
  user:        Martin Geisler <mg at daimi.au.dk>
  date:        Thu Mar 20 11:24:31 2008 +0100
  summary (updated in 2:62164c94d09b): Fixed bug #123.

  changeset:   0:f33c4b862172
  user:        Martin Geisler <mg at daimi.au.dk>
  date:        Thu Mar 20 11:24:12 2008 +0100
  summary:     Added foo.c.

>>> 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.
>
> A centralized wiki would rather contradict the distributed nature of a
> DVCS. And if one is going to maintain the commit messages outside the
> VCS, what point in even supplying commit messages to the VCS?

Exactly, there would be no point in giving a commit messages to Hg :-)
Instead you could just commit with an empty message, then go create a
Wiki page with the resulting hash value as its name and write the
message there.

That would be quite impractical though... :-)

-- 
Martin Geisler

VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
SMPC (Secure Multi-Party Computation) to Python. See: http://viff.dk/.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://selenic.com/pipermail/mercurial/attachments/20080320/767bc524/attachment.pgp 


More information about the Mercurial mailing list