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

Idan Kamara idankk86 at gmail.com
Thu Feb 2 06:55:32 CST 2012


On Thu, Feb 2, 2012 at 2:45 PM, Angel Ezquerra <angel.ezquerra at gmail.com>wrote:

> On Thu, Feb 2, 2012 at 1:35 PM, Idan Kamara <idankk86 at gmail.com> 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
> >
> > 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).
> >
> > This is an RFC, which last discussed one year ago:
> http://markmail.org/message/skalggb4typm27um
> >
> > I think this attempt is less intrusive and more contained than the
> previous one
> > (it was done quickly to see if there's interest, so still unfinished),
> with a
> > much cleaner implementation (largely due to parren's work on evolution,
> thanks ;).
> >
> > It doesn't try to be too smart, and now that we have phases it should be
> safe.
> >
> > This is arguably one of the most common history editing operations. I
> don't
> > think referring people to mq (or rollback, which is worse) for this is
> particularly good.
> > It requires activating a 'heavy' extension and use new commands that the
> user
> > isn't familiar with. This way the user is in familiar territory, knowing
> all the flags etc.
> >
>
> This is quite cool and a neat example of what can be done now that
> mercurial tracks phases :-)
>
> One thing that would be nice is to be able to just "amend" the commit
> message (without modifying the patch file contents). I think _that_ is
> probably _the_ most commonly requested history editing operation (at
> least in my experience).
>

Right. I didn't take care of that yet and due to the current implementation
it fails with a 'nothing changed' message. But it should be doable.


>
> Angel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20120202/d4e703fe/attachment.html>


More information about the Mercurial-devel mailing list