[RFC] Amend commit messages
Laurens Holst
laurens at grauw.nl
Wed Feb 23 12:44:25 UTC 2011
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>
More information about the Mercurial-devel
mailing list