<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><blockquote type="cite"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; "><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><div><div><br></div><div>I agree with Idan here. '--amend' on commit to me is the obvious place for the</div><div>simple amend operation. (For comparison it's in the commit dialog for MacHg</div><div>where I added this check box), also in git it's a straight forward '--amend'</div><div>argument to git commit.</div><div><br></div><div><div><div>(Also, you objecting to this is somewhat surprising since you have just finished</div><div>adding a single command "phase" which does two radically different things</div><div>sets-the-phase and reports-the-phase depending soley on options. So here the</div><div>small semantic tweak of amend versus commit being an option is comparable</div><div>trivial.)</div></div></div><div><br></div></div></div><div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; ">
<div>> 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><br></div><div><div><div>As for wether "amend" is an extension or not, I would be tempted to say most</div><div>things even say your recent "phases" should likely be extensions until all the</div><div>kinks have been worked out. Once something is an extension is really the first</div><div>time that lots of people are going to use it / experiment with it. Then once the</div><div>kinks are worked out move it into core. So having --amend as an extension for</div><div>say 3 months, would be fine. It also might make sense to have it as an extension</div><div>until such time as your concept / proposal of "obsolete" is fully integrated...</div><div><br></div><div>Cheers,</div><div>  Jason</div></div></div></body></html>