[PATCH RFC] commit: add --amend option to amend the parent changeset

Alain Leufroy alain.leufroy at logilab.fr
Thu Feb 23 04:08:44 CST 2012

On Mon, 20 Feb 2012, Martin Geisler wrote:

> Idan Kamara <idankk86 at gmail.com> writes:
> > On Mon, Feb 20, 2012 at 8:47 AM, Martin Geisler <mg at lazybytes.net> wrote:
> >>
> >> In that way, 'hg commit --amend' becomes very much like
> >>
> >>  hg rollback; hg commit -l .hg/last-message.txt
> >>
> >> with the twist that the editor is started even though a commit
> >> message is given on the command line.
> >
> > Sometimes you might be doing several commits and only when you're
> > about to push you review them and realize you've made a mistake.
> Yeah, that happens regularly for me too.
> > So I think it's also useful to amend a changeset with children (and
> > then manually rebasing those to the amended commit, which raises the
> > question whether rebase preserves date/user, and it turns out it
> > does).
> I feel that this is outside the scope of 'hg commit --amend'. I see that
> flag as a safe way to do 'hg rollback; hg commit'. It's true that this
> is limited and wont fix all problems, but if we keep the flag simple,
> then we can the first history editing command into core!

I think that we shouldn't add another destructive operation on the graph: I
think that removing information is not a good idea (and does not fit the Hg

The obsolete relation seems to be a good candidate to allow non-destructive
graph evolution (I prefere the semantic of "evolution" rather than the
 semantic of "rewriting"). It will give a sound way to (re)write funny and
powerfull tools.

> More advanced history or commit message editing could then be provided
> by another command (such as histedit).

Alain Leufroy
LOGILAB, Paris (France)
Informatique scientifique & gestion de connaissances

More information about the Mercurial-devel mailing list