[RFC] Amend commit messages

[Gilles Moris]

On Wednesday 23 February 2011 11:18:44 am Jason Harris wrote:
> Hi,
>
> This is at a slightly different tangent to your question:
> > "I made a mistake in my commit message. How can I change it?"
>
> The question largely is one directed at history editing... Of course there
> are questions about have the changes been pushed, etc...
>
> From a personal point of view I just think we should have the option
> --amend to the commit command that basically does:
>
> hg qimport -r tip ; hg qrefresh -e ; hg qfinish tip
>
> Just like it says in http://mercurial.selenic.com/wiki/GitConcepts.
>
> This gets around probably 60% of the problems.
>
> I mean git users use this and they are not killing themselves with it. In
> fact I implemented exactly this option in MacHg and its wonderful. See this
> screenshot:
>
> AmendOption.png
>
> Then the other 40% of the problem is to hurry up LiquidHg.
>
> I don't know about everybody else but I tend to work on my code for a while
> adding, polishing moving bits around and then push stuff in a clump. I do a
> lot of "history editing" before I push. My typical workflow and I would
> assume that of others is: A lot of time with development there are small
> little tweaks. I often commit before I compile just in case I mess
> something up.  Then I start testing the new code. I will often then find
> some simple typos, or maybe a missing include or something. Then I simply
> do an amend commit, and then once its compiling the next changes either go
> in their own commits if they are bigger or in that one if they were simple
> small oversights.
>
> (I will often use histedit to move things around until they are in a nice
> order for later historical understanding so that when I or someone else
> looks back 6 months from now I / they have some hope of following what I
> was doing. In fact I often don't worry too much about the commit message. I
> often go back once things are moved around and organized into shape and
> change the commit messages to something detailed and sensible... Of course
> I do this on the stuff I haven't yet pushed to the wider world. Note to do
> this editing I often make throw away clones just in case something goes
> wrong with the history editing process, so I can just step back to where I
> was. At some stage it would be really nice to have a wider undo, rather
> than the limited rollback we now have... But thats the topic for other
> emails...)
>

I am not trying to do history editing of liquid changesets here. You can do 
whatever histedit or mq while your changesets are still liquid. My point is 
for frozen changesets.

For file content, you can just make another commit to fix your error. For 
commit message, there is currently no solution.
- You say it would be rare that you really need to do that. That's true, but 
whatever the number of reviews before integration, it will never be zero. We 
are currently based on CVS (switching to HG Hurray!) with a readonly DB to 
track integrations, and I manage that kind of request several times par week.
- You say this is not a big deal. Usually yes, but if you point to an 
incorrect bug number or commit reference, you may find out in your papers you 
have made a mistake a week ago, but have hard time one year later to recover 
that information.

> <general comment on history editing>
> I commit early and very often. But many of my commits are not logical
> chunks or they go down blind alleys etc. Thus history editing is really
> really useful. In fact one of the largest examples of this close to home
> that we all have experience with here is the Mercurial source code itself.
> The commit history for the Mercurial project itself is quite clean and the
> quality level of the patches before they are applied to the mercurial
> sources is quite high. There are very few: "Opps, include that header",
> "Opps change the spelling here", "Opps, make sure it compiles under linux",
> "Opps, make sure it passes this test", etc. sorts of commits in the
> Mercurial source tree. Thus in one way or another the ethos behind the
> Mercurial project's revision history is a clean one.
>
> Consequently it appears to me that its somewhat iniquitous to see that the
> Mercurial project itself keeps a very clean history where the patches sent
> in have obviously been history edited in one way or another, but tends to
> espouse the position that history editing is evil, and all you people just
> keep whatever intermediate erroneous commits in your repository because its
> good for you. (even though we don't keep them in our history ourselves...)
>
> Note of course the position might be, well if you are committing to
> mercurial then you are an advanced user of mercurial and you know about
> history editing and you know its not so evil (just don't tell others) since
> we want to keep the general message for the non-advanced users that history
> editing is dangerous.
>
> In any case the clear shining example here is that the Mercurial sources
> themselves are clean from the "opps" sorts of commits. So somehow users
> would also like to have similarly clean and followable commit histories.
> </general comment on history editing>
>
> So in reference to the below:
>
> 1. It seems like the scheme you are proposing below just seems like it will
> be adding layers of complexity.

Yes, but difficult to have everything for free, right?

> 2. Everyone on your team would need to be using the extension to get this
> layered change to history.

Yes and no. Even if you don't have the extension, you can still look if you 
have an amendment file for this commit. Very easy to do. The extension only 
conveniently patch the log.
Having that into the core of course would solve the remark, though is possibly 
too early for that.

> 3. This will only ever change the commit message. Easily over half of my
> opps commits are small typos in the code.

Usually, but sometimes not. I even met the case where the commit message was 
about a similar but unrelated fix.

> 4. Once I have cleaned up my commits before pushing the incidence of wrong
> commit messages is very low. For instance in the Mercurial source tree how
> many messages would we really need to change?

Very low but not null. As I said, I have this kind of request regularly from 
my team.

>
> Hopefully with the LiquidHg extensions all this will be safe and users will
> know exactly when they are about to change stuff which has already gone out
> to the wider world...
>

I don't think Liquid will change. Liquid will change the entire changeset of 
not yet frozen commits. This is not what I am trying to address.

Regards.
Gilles.