[RFC] Amend commit messages

[Laurens Holst]

Op 23-2-2011 13:18, Martin Geisler schreef:
> Laurens Holst<laurens.nospam at grauw.nl>  writes:
>
>> I don’t think it’s necessary, or desirable.
>>
>> It doesn’t happen that often, and when it does, usually you still have
>> the opportunity to do hg rollback or even to edit it with MQ or
>> histedit as you said.
>>
>> If you’ve pushed out the changes already, then zut, so be it.
>> Honestly, it’s really not a big deal to have a less-than-perfect
>> commit message. Can’t change commit messages at all with SVN once
>> you’ve committed, I think with the existing possibilities Mercurial is
>> already a lot more powerful than that.
> You can actually change these so-called revision properties with
> Subversion, but it requires that the server has been configured to allow
> it. First you enable the rev-prop-change hook
>
>    $ ln -s /bin/true<repo>/hooks/pre-revprop-change
>
> and then you can change things like the author:
>
>    $ svn propset --revprop -r HEAD svn:author "alice"
>
> Voila, mutable history in SVN!

Ah I was not aware of this. (Altering history seems a bit scary when you 
don’t have a local repository to experiment in.) But either way, we’ve 
never used this at work and we survived just fine. Yes, in a few cases 
it mentions a wrong bug or revision number, or the commit message is 
unfinished — oh well, odds are that no-one will actually look at it 
anyway. I’m pretty sure this is not really commonly used SVN functionality?

Sometimes wished I had *something*, but actually Mercurial’s current 
capabilities address that wish perfectly. That’s why I think this is 
taking it a little too far.

>> Taking it further seems to me like taking it too far, and hurting the
>> immutable history principle. In fact, the ability to edit history
>> already leads me to the tendency spend a lot of time on tidying it up
>> that I really shouldn’t be spending, and is also actually pretty
>> dangerous, you can lose your changes with relative ease. (Hopefully
>> with the dead branches functionality it’ll be less dangerous.)
> It is still immutable in the sense that you don't mess with the existing
> history -- you only add an overlay.

Mjeh, but you alter it as far as the user’s perception is concerned, and 
that’s what matters. This of course also happens with files, but there 
you have the log / repository explorer to see how they changed.

What you propose is introducing a similar thing on a meta-level, and for 
this there’s not even a simple way to see the message was altered, much 
less an easy and expected way to view this history; you have to do odd 
things to see the real-real history (like the clone -r as suggested by 
Gilles, or disabling the extension which is kind of a hack too - if it 
were core functionality this wouldn’t be possible).

Also I would argue that currently one of the big things Mercurial has 
going for it is that its history model is easy to understand. Adding 
this kind of additional layers to it doesn’t exactly simplify matters.

So, I’m just not a really fan of this kind of practice :), and the use 
case seems limited. My 2 cents :).

~Laurens

-- 
~~ Ushiko-san! Kimi wa doushite, Ushiko-san nan da!! ~~
Laurens Holst, developer, Utrecht, the Netherlands
Website: www.grauw.nl. Backbase employee; www.backbase.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: laurens.vcf
Type: text/x-vcard
Size: 160 bytes
Desc: not available
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20110223/b62e6435/attachment.vcf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6006 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20110223/b62e6435/attachment.bin>