[RFC] Amend commit messages

Martin Geisler mg at aragost.com
Wed Feb 23 04:00:41 CST 2011


Gilles Moris <gilles.moris at free.fr> writes:

> 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?"

Yeah, I've thought about solving this problem too...

> Now see how the something else can structured:
>
> - as a single ".hgmessage" file located in the working directory, much
> like .hgtags". However this is more complex to handle than tags, as
> commit message can be multi-lines. This would require some markup
> language to delineate the mapping between the commit identifier and
> the message content. This would be specifically a problem during
> merges of this file, which would require knowledge of the format and
> increase the risk of incorrectly merge this file.

Yes, that would be cumbersome and error-prone...

> - the second solution is to create a ".hgmessage" directory this time,
> and have file for each commit amended. The file name is the full hex
> SHA1 identifier of the amended commit and the content is just the new
> commit message. This lowers the risk of merge, and in case of merge it
> is quite straightforward to understand how to merge. However, this
> risk is not null. The problem here is that the commit message
> description history is intermangled with the regular code history. If
> the commit amendments are made in 2 different branches that are not
> supposed to be merged from a code standpoint, we're stuck with also 2
> divergent commit descriptions.
>
> - so I came up with a third solution which is to put the commit
> messages in their owned named branch "hgmessage". That way the
> amendment history is decorrelated from the code history. The need to
> amend a commit message should be sufficiently rare that the overhead
> of a separate branch is acceptable.

I would suggest a fourth solution: store the overlay commit messages
outside of the history and use the pushkey mechanism to transfer them
between repositories on push and pull.

The advantages:

* no new changesets to clutter the graph

* changes to the overlays are not stored -- you can edit your commit
  message as often as you like and it wont leave a trace. This is just
  like doing 'hg qrefresh' again and again.

Disadvantages:

* changes to the overlays are not stored -- no trace of who edited an
  overlay message last and why.

* handling of merges must be done manually -- with the messages stored
  as real files in the history conflicts can be solved just like normal,
  and even automatically in some cases.

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://aragost.com/en/services/mercurial/blog/


More information about the Mercurial-devel mailing list