[PATCH RFC] commit: add --amend option to amend the parent changeset
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:
> 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
> history rewriting operation in core. History rewriting operation usually
> to work around common issue that obsolete could handle in a common and
> way (eg: amend changeset with children). Having obsolete documented and
> 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
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
'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
> effort solution" that will get into the way of graceful solution using
What's not graceful about this?
> I made minor update to the wiki page related to the obsolete concept for
> who missed previous discussion on the subject. I'll write more details
> in the comming weeks. I expects the obsolete concepts to be discussed this
> cycle (2.2) and implemented the next (2.3)
>  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
> 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
> > 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
> > 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
> > 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
> 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
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> -----END PGP SIGNATURE-----
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mercurial-devel