[RFC] Amend commit messages

[Didly]

On Wed, Feb 23, 2011 at 1:47 PM, Laurens Holst <laurens.nospam at grauw.nl>wrote:

> 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


I totally disagree. Perhaps having a typo in the commit history is bad, but
what if you realize that you mention the wrong Change Request? There are
automated tools that use this sort of information to tell whether a CR is
done or has been worked on and an invalid commit message can be disastrous.

Another scenario where this may come handy is when the commit message says
something that is later found out to be untrue, such as when it says: "Fixed
such bug" and later on you discover that this is not the case.

Plus, "How do I fix my commit message" is probably the #1 question I get as
the person in charge of mercurial supporting in my company, so a clean
answer to that question would make me very happy :-)

So I must say that I think this idea is great and I'd really like to see a
polished implementation of this concept distributed with mercurial at some
point. I think the way it has been designed, amending rather than modifying
the history is very nice too. If mq, which is 1000x more dangerous than this
is distributed with mercurial , I don't see why something so much more
harmless as this is could not be distributed with mercurial as well.

Cheers,

Angel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20110223/50fd0359/attachment.htm>