[RFC] Amend commit messages

[Gilles Moris]

On Wednesday 23 February 2011 11:00:41 am Martin Geisler wrote:
> 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.

Yes, that's true. I considered that solution at one point of time also.
What I did not like at all was the lack of accountability. I want to have some 
history log of who and when a message has been changed ("Huh! Who changed my 
commit message?"), and possibly what was changed exactly. With pushkey, I 
would have to recode all or part of the history management when it comes for 
free with regular commit.
Plus I guess you have to explicitly push those meta-information with pushkey, 
right? Or this is a specific implementation of bookmarks.

But the accountability thing is really the one that kept me for looking in 
that direction. For bookmarks, or for optional information, for instance if 
it was user name aliases, this would be acceptable. But I do not feel this is 
for commit message.

Regards.
Gilles.