[RFC] Amend commit messages

Mads Kiilerich mads at kiilerich.com
Wed Feb 23 11:03:02 CST 2011


On 02/23/2011 09:41 AM, Gilles Moris wrote:
> Hello,
>
> I don't remember any extension in this area, but this is a recurrent question
> on the mailing list:
> "I made a mistake in my commit message. How can I change it?"
>
> We can redirect them to either mq or histedit, but usually we can only answer
> that this is not possible if the commit is already published.
> However, this question is legitimate. Whatever the number of reviews you can
> do, there always be some typo that can escape, like switched digits in a bug
> number or similar issues. The idea to have a message forever wrong is quite
> frustrating.
>
> 1. Goal
> The goal is to overlay another commit description to replace a previous commit
> message. The current history (committed SHA1) is not changed and those commit
> message amendments appear as additional commits.

I think it would improve the description of your concept and help the 
perception if you made it even more clear that the purpose wasn't to 
modify history but view history in a different way.

I think that a consequence of that point of view is that descriptions 
shouldn't be modified in lower levels of Mercurial, but the presentation 
layer could show something else instead of or in addition to the commit 
message.

(With a parallel to real life: what happened happened (but it was never 
fully understood) and what was written was written (but rarely agreed 
upon). What changes is the understanding and interpretation of the past. 
That doesn't change history (even though it might become a part of 
history by "appending").)

If someone wants a nice and error free history then they must ensure 
that with workflows that ensures that great care is taken and thorough 
reviews done. Mercurial is good at tracking history but rather weak in 
the "pre-historic" phase - the shiny imaginary liquid concept might 
improve that. (It could be argued that git has the opposite properties: 
it is good at mutating changes but not so good at persisting them.)

Workflows that relies on the "correctness" of changeset descriptions 
shouldn't use changeset descriptions but "something else". As I 
understand it you want to introduce that "something else". That could be 
cool, but please make it clear that it is "something else".

References to fixed bugs and release notes are examples of things where 
the intention of the changes might be known at commit time, but it is 
often not correct and subject to change, so if this kind of information 
has to be reliable it shouldn't be in the commit message. (Another 
reason is that it often spans multiple changesets.)


Note that another extension that also creates an alternative view on 
history is http://mercurial.selenic.com/wiki/GroupExtension . It seems 
like it to some extent provides the same functionality.


I think these problems and their possible solutions and their issues 
have a lot in common with how Mercurial tags were designed 
(http://mercurial.selenic.com/wiki/TagDesign )

One rationale for the tag design was that "parallel repositores" wasn't 
feasible. Now we have subrepositories. "After the fact" tagging could be 
stored in a meta-repository in which the real repository is a subrepo. 
(Tagging while committing could be done with named branches and some hacks.)

I'm not (necessarily) proposing that we should have another tag design, 
but the idea of using a meta-repository for storing mutable meta 
information (such as these mutable after-the-fact descriptions of 
changesets) could perhaps be considered.

/Mads


More information about the Mercurial-devel mailing list