[PATCH RFC] commit: add --amend option to amend the parent changeset
Pierre-Yves David
pierre-yves.david at logilab.fr
Mon Feb 6 12:41:16 UTC 2012
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.
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.
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.
> 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.
--
Pierre-Yves David
http://www.logilab.fr/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-devel/attachments/20120206/b9a7bc7c/attachment.asc>
More information about the Mercurial-devel
mailing list