[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