<div dir="ltr"><div class="gmail_quote">On Mon, Feb 6, 2012 at 2:41 PM, Pierre-Yves David <span dir="ltr"><<a href="mailto:pierre-yves.david@logilab.fr" target="_blank">pierre-yves.david@logilab.fr</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Before commenting on the RFC itself, I would like to point that we also have an<br>
implementation of an amend command here:<br>
<br>
    <a href="http://hg-dev.octopoid.net/hgwebdir.cgi/mutable-history/file/64d16f07d67f/hgext/evolution.py#l277" target="_blank">http://hg-dev.octopoid.net/hgwebdir.cgi/mutable-history/file/64d16f07d67f/hgext/evolution.py#l277</a><br>


<br>
This implemenentation handle several cases including "commit message<br>
rewritting" (including when no change found) and "altering branch". You<br>
probably want to have a look at it.<br>
<br>
<br>
Moreover, I do feel we better work on having obsolete done before putting new<br>
history rewriting operation in core. History rewriting operation usually have<br>
to work around common issue that obsolete could handle in a common and graceful<br>
way (eg: amend changeset with children). Having obsolete documented and done<br>
will help us to shape a consistent UI for history rewriting operation too.<br></blockquote><div><br></div><div>I look forward to discussions on this concept but I don't think it is mutually exclusive</div><div>with this patch (and by the looks of it, they even share some logic).</div>
<div><br></div><div>Like I said in the commit message, this new option to 'hg commit' is trying to solve a</div><div>simple problem with a simple solution. From the (little) documentation I've read about</div>
<div>'obsolete', using it for this particular problem feels like killing a bug with an Ion Cannon.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Anyway, I won't bame people working on that front but I'll frown to any "best<br>
effort solution" that will get into the way of graceful solution using obsolete<br>
changeset.<br></blockquote><div><br></div><div>What's not graceful about this?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I made minor update to the wiki page related to the obsolete concept for those<br>
who missed previous discussion on the subject[1]. I'll write more details down<br>
in the comming weeks.  I expects the obsolete concepts to be discussed this<br>
cycle (2.2) and implemented the next (2.3)<br>
<br>
[1] <a href="http://mercurial.selenic.com/wiki/ChangesetEvolution" target="_blank">http://mercurial.selenic.com/wiki/ChangesetEvolution</a><br>
<div><br>
<br>
On Thu, Feb 02, 2012 at 02:35:03PM +0200, Idan Kamara wrote:<br>
> # HG changeset patch<br>
> # User Idan Kamara <<a href="mailto:idankk86@gmail.com" target="_blank">idankk86@gmail.com</a>><br>
> # Date 1328185747 -7200<br>
> # Branch stable<br>
> # Node ID cc7dec00d5016f03acf789c35ce6ef50b204f0cb<br>
> # Parent  0620421044a2bcaafd054a6ee454614888699de8<br>
> commit: add --amend option to amend the parent changeset<br>
<br>
</div>I do not think this should be a flag to commit. "hg commit" is about adding new<br>
changeset to the history. Your RFC is about rewriting a changeset. I would use<br>
a dedicated command "hg amend" for this purpose.<br></blockquote><div><br></div><div>I actually like it being on commit, it's the obvious place. It doesn't require</div><div>"learning" a new command, which in this case has the exact same flags too.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
> Commits a new changeset incorporating both the changes to the given files<br>
> and all the changes from the current parent changeset into the repository.<br>
><br>
> You cannot amend public changesets. Amending a changeset with children<br>
> results in a warning (we might want to forbid this).<br>
><br>
> Behind the scenes, first commit the update as a regular child of the current<br>
> parent. Then create a new commit on the parent's parents with the updated<br>
> contents. Then change the working copy parent to this new combined changeset.<br>
> Finally, strip the intermediate commit created in the beginning (might<br>
> want to also strip the amended commit if it has no children).<br>
<br>
</div>I do not think we should make this part of core yet. Core is currently free of<br>
history rewriting stuff and this look like a good idea. I would put that in an<br>
extension until we have alternative to strip in core. In a general manner I<br>
will be overcautious about setting history rewriting operation into core store<br>
until we have more hindsight.<br></blockquote><div><br></div><div>I like extensions. I think some of them are great. But if the average user has</div><div>5-10 extensions enabled, then that's bad. This feels like something the</div>
<div>average user would want in his toolbox.</div><div><br></div><div>If X out of Y users (where X is say Y/2) who come to IRC ask</div><div>"how do I do Z in Mercurial?" and the answer is "use extension foo",</div>
<div>then foo shouldn't be an extension.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span><font color="#888888"><br>
--<br>
Pierre-Yves David<br>
<br>
<a href="http://www.logilab.fr/" target="_blank">http://www.logilab.fr/</a><br>
<br>
</font></span><br>-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.10 (GNU/Linux)<br>
<br>
iEYEARECAAYFAk8vymwACgkQElczi7p/bN+akgCeIG2F3uO5T06d2SUF+/KL9tGb<br>
tEUAn2i+PyvoTWoxcfju/FpYI/9lmF1J<br>
=uP4G<br>
-----END PGP SIGNATURE-----<br>
<br></blockquote></div><br></div>