[RFC] Amend commit messages

[Gilles Moris]

On Wednesday 23 February 2011 02:20:48 pm Laurens Holst wrote:
> Op 23-2-2011 9:41, Gilles Moris schreef:
> > 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.
>
> Also, does the same not apply to files? ‘I checked in a file I didn’t
> intend to. How can I change it?’
>
> It’s the same class of error, made in the same window. I certainly make
> this mistake as much as I make mistakes in my commit message. Also the
> answer is the same: you can rollback and retry immediately, or with some
> more effort amend before you push. After you push, it’s permanent.
> Simple. And plenty of opportunity to realise and fix your mistake.
>
> A nice aspect of this I think is that it has ‘gradations of penalties’,
> through which it teaches you to be careful when committing and pushing
> changes.
>
> Didn’t review what you were about to commit? You have to waste time
> doing the commit over. Only realise that you made a mistake after you
> made other commits? Go through the additional effort of altering your
> local history, or don’t bother. Still didn’t realise your mistake when
> you pushed? Either you get admin access to the central repo and inform
> the whole department that they need to re-pull their repos, or don’t
> bother. Even at this point it’s still possible, just the cost really
> starts to outweigh the benefit.
>
> So I suppose you could even argue that lowering this cost of altering
> history could make people more careless in their commits :).
>
> ~Laurens

All this is only possible for a time window of a few hours after you push.
When you made really made a mistake in the file content, you can use "hg 
backout", or you can fix it by a new commit. You know that your code was 
wrong, but you have a trace in the history how you fix it.

When a commit message is wrong and there are days of works on top, there is 
currently not much you can do except live with it. No way you can signal 
others that this was wrong. Except some errata file you hope other will read.

So may be you can have 10 independent reviewers that scrutinize each word and 
bits of a commit, but then this cost may outweight the need to have perfect 
commits upfront. And you're back with the let's live with it.
It wasn't my point to be permissive for reviews. Actually, I think it is a 
good thing that the extension history is handled in a separate branch, so 
that it's not to easy to manage.

Anyway I guess it's better for this to stay as an extension as it will be 
difficult to find a consensus on that.

Regards.
Gilles.