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

Idan Kamara idankk86 at gmail.com
Mon Feb 6 08:08:39 CST 2012

On Mon, Feb 6, 2012 at 2:41 PM, Pierre-Yves David <
pierre-yves.david at logilab.fr> wrote:

> Before commenting on the RFC itself, I would like to point that we also
> have an
> implementation of an amend command here:
> http://hg-dev.octopoid.net/hgwebdir.cgi/mutable-history/file/64d16f07d67f/hgext/evolution.py#l277
> This implemenentation handle several cases including "commit message
> rewritting" (including when no change found) and "altering branch". You
> probably want to have a look at it.
> Moreover, I do feel we better work on having obsolete done before putting
> new
> history rewriting operation in core. History rewriting operation usually
> have
> to work around common issue that obsolete could handle in a common and
> graceful
> way (eg: amend changeset with children). Having obsolete documented and
> done
> will help us to shape a consistent UI for history rewriting operation too.

I look forward to discussions on this concept but I don't think it is
mutually exclusive
with this patch (and by the looks of it, they even share some logic).

Like I said in the commit message, this new option to 'hg commit' is trying
to solve a
simple problem with a simple solution. From the (little) documentation I've
read about
'obsolete', using it for this particular problem feels like killing a bug
with an Ion Cannon.

> Anyway, I won't bame people working on that front but I'll frown to any
> "best
> effort solution" that will get into the way of graceful solution using
> obsolete
> changeset.

What's not graceful about this?

> I made minor update to the wiki page related to the obsolete concept for
> those
> who missed previous discussion on the subject[1]. I'll write more details
> down
> in the comming weeks.  I expects the obsolete concepts to be discussed this
> cycle (2.2) and implemented the next (2.3)
> [1] http://mercurial.selenic.com/wiki/ChangesetEvolution
> On Thu, Feb 02, 2012 at 02:35:03PM +0200, Idan Kamara wrote:
> > # HG changeset patch
> > # User Idan Kamara <idankk86 at gmail.com>
> > # Date 1328185747 -7200
> > # Branch stable
> > # Node ID cc7dec00d5016f03acf789c35ce6ef50b204f0cb
> > # Parent  0620421044a2bcaafd054a6ee454614888699de8
> > commit: add --amend option to amend the parent changeset
> I do not think this should be a flag to commit. "hg commit" is about
> adding new
> changeset to the history. Your RFC is about rewriting a changeset. I would
> use
> a dedicated command "hg amend" for this purpose.

I actually like it being on commit, it's the obvious place. It doesn't
"learning" a new command, which in this case has the exact same flags too.

> > Commits a new changeset incorporating both the changes to the given files
> > and all the changes from the current parent changeset into the
> repository.
> >
> > You cannot amend public changesets. Amending a changeset with children
> > results in a warning (we might want to forbid this).
> >
> > Behind the scenes, first commit the update as a regular child of the
> current
> > parent. Then create a new commit on the parent's parents with the updated
> > contents. Then change the working copy parent to this new combined
> changeset.
> > Finally, strip the intermediate commit created in the beginning (might
> > want to also strip the amended commit if it has no children).
> I do not think we should make this part of core yet. Core is currently
> free of
> history rewriting stuff and this look like a good idea. I would put that
> in an
> extension until we have alternative to strip in core. In a general manner I
> will be overcautious about setting history rewriting operation into core
> store
> until we have more hindsight.

I like extensions. I think some of them are great. But if the average user
5-10 extensions enabled, then that's bad. This feels like something the
average user would want in his toolbox.

If X out of Y users (where X is say Y/2) who come to IRC ask
"how do I do Z in Mercurial?" and the answer is "use extension foo",
then foo shouldn't be an extension.

> --
> Pierre-Yves David
> http://www.logilab.fr/
> Version: GnuPG v1.4.10 (GNU/Linux)
> iEYEARECAAYFAk8vymwACgkQElczi7p/bN+akgCeIG2F3uO5T06d2SUF+/KL9tGb
> tEUAn2i+PyvoTWoxcfju/FpYI/9lmF1J
> =uP4G
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20120206/fa715850/attachment.html>

More information about the Mercurial-devel mailing list