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

[Jason Harris]

>>>>> 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.
>>>> 
>>> 
>>> I like extensions. I think some of them are great. But if the average user
>>> has 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.
>> 
>> I'm not saying this should never be in core. But I think this should
>> start being and extension. In particular until we have safer mechanism than
>> strip to mark replaced changeset.
>> 
>> Experimenting outside core is a good way to make thing available while keeping
>> space to tune the UI with feedback.
>> 
>> I believe we can wait a few months before making it part of core.
> 
> I don't mind if others think this is necessary.
> 
> Anyway, to sum this RFC up, it looks like there's no real support for this,
> so I'm not going to finish this until others voice their opinion.

Wait a second, I think '--amend' is a great idea! Angel also thought it was a
good idea and it seemed Matt asked some interesting questions, like "would it
work with amending a merge?". (I would also really like it to work with amending
a merge as well. Currently with tricky merges I often commit fixes to the merge
afterwards, then redo the merge and then revert all files to the final fixed
version commit the new merge, then finally strip my "development merge+fixes".
So being able to amend the merge would be very nice since currently collapse
with a trailing merge changeset doesn't work (or didn't the last time I played
with it).

I think the only one that seemed against it was Pierre and I don't agree with
his reasoning at all. And maybe to sum up his main objections was this should be
outside core for now, which maybe he is correct, maybe not. As a user facing
thing the '--amend' option is very simple and clear cut and simple, it's a very
popular option in git and it can be made to "just-do-the-right-thing". I don't
really see any controversy around it.

Pierre's Obsolete concept may or may not come but it surely is massively
more complex then a simple '--amend' option which we would likely want in any
case. It's currently what people do all the time using MQ so being able to
simplify things and use --amend is very desirably here.

Cheers,
   Jason