Rollback ate my commit message! (issue 1635)

Douglas Philips dgou at
Wed Nov 18 13:25:48 CST 2009

On or about 2009 Nov 18, at 1:48 PM, Martin Geisler indited:
> Greg Ward writes:
>> Sure, there are lots of ways I could fix this that benefit only me  
>> and
>> my colleagues.  But this annoyance can affect anyone using Mercurial.
>> ("Oops! typo in that commit message! I'll just rollback and fix  
>> it ...
>> oh. wait. rollback ate my commit message.  @^%!^@^@#")  And it's even
>> more likely to bite anyone using a pretxncommit hook with teeth.
> It seems to me that rollback is being used too much -- we should  
> instead
> have an extension that will let people edit the commit messages.

I'm not sure that I agree. Rollback is good for a lot more than just  
revising commit messages. Ooops, I just pulled from the experimental  
repo (yanked back the wrong command, brain-o of some other kind), etc.

> I've always seen rollback as a low-level command that just happens  
> to be
> useful for quickly redoing a commit. It's low-level since it's so
> limited: there's no indication of what will happen and there's only  
> one
> rollback point.

I've always seen rollback as having bugs:
	It knows, but won't tell you, where it will rollback to.
	Rollback info is strictly hierarchical, so there is no reason  
(theoretically), that it couldn't nest. Strip tends to take up the  
slack here instead.

> A proper command that is meant to be used regularly
> should not have such a simple interface. I would almost say that
> rollback should have been a debug command.

So we'll have an 'unpull' command and ...
Rollback fits with the unix philosophy. With a verbose and dry-run  
options it would quite useful, IMHO, as it fits with the *nix  
philosophy of having simple compose-able parts.


More information about the Mercurial-devel mailing list