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

[Idan Kamara]

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
require
"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
has
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/
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAk8vymwACgkQElczi7p/bN+akgCeIG2F3uO5T06d2SUF+/KL9tGb
> tEUAn2i+PyvoTWoxcfju/FpYI/9lmF1J
> =uP4G
> -----END PGP SIGNATURE-----
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20120206/fa715850/attachment.html>