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

[Pierre-Yves David]

On 24 févr. 2012, at 20:40, Augie Fackler wrote:

> 
> On Feb 24, 2012, at 11:55 AM, Pierre-Yves David wrote:
> 
>> On Thu, Feb 23, 2012 at 12:58:47PM +0200, Idan Kamara wrote:
>>> On Thu, Feb 2, 2012 at 2:35 PM, Idan Kamara <idankk86 at gmail.com> 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
>>> 
>>> 
>>> Ok, after 40 messages in this RFC, I think we should sum this up:
>> 
>> Thanks for this sum-up and making the topic moving forward. Bellow I sum up how
>> my opinion evolved on this point.
>> 
>>> - hg amend vs hg commit --amend: pretty much a tie but mpm on board with --amend,
>>> going with --amend.
>> 
>> If this does not prevent (or make it too complicated) to add a more powerful
>> and dedicated amend command, this solution seems ok. I've read pretty
>> convincing argument for such duality.
>> 
>> A "commit --amend" switch. It has limited feature and aims to help making small
>> ajustement to a commit. Non-frequent usage.
>> 
>> A "amend" decicated command. A more featured command aimed to people that are
>> heavily shaping their history. It'll have more option and maybe sightly
>> different default. Think it a replacement of qrefresh
>> 
>> I'm not saying the amend command must be implemented at the same time than the
>> --amend switch. Acknowledging it's future existance will ease the decision
>> process on several point.
>> 
>> 
>>> - allow amend on non-head with a warning: most were against this. going to abort.
>> 
>> I agree that'll be far too complicated until we have obsolete marker. Aborting
>> for now make sense. Restricting this usage to dedicated command later is
>> probably the way to go..
>> 
>>> - open editor by default with old commit message (no --edit): opinions vary,
>>> going with this for now.
>> 
>> If it aims to unfrequent usage it is probably okay to open the editor by
>> default. To cover more heavy usage we need either a --edit or --no-edit
>> (according the picked default)
> 
> FWIW, 'git commit -a --amend' pops an editor for revising the commit message, and in my limited use of the feature it's not been annoying.
> 
>> 
>> Using a dedicated command for heavy usage allow a simpler implementation of the
>> flag.
>> 
>> 
>> Note: having the ability to use "-l in commit" and still open the editor would be awesome.
>> This lean in the direction of an --edit flag that make sense on commit.
>> 
>> 
>>> - keep old user/date on new commit: opinions also vary, but seems better than
>>> the opposite (so we can add -U/-D rather than --keep-user/date).
>> 
>> +1, fixing a typo in contributors patches should not change ownership.
>> 
>>> - strip amended commit: some think we shouldn't, didn't see a conclusive argument
>>> why and how the user is going to avoid pushing the old commit.
>> 
>> In my mind the question is more: If we strip, shall we do backup ?
>> 
>> Not doing backup is a very bad idea immo. But doing Frequent bundle will bring
>> trouble too for heavy usage.
> 
> I dunno. Backups are pretty small on the whole, and we can improve the situation.

Depends. As we do not compute any delta, backup size of N amend is "O(N) x size-changeset" for some big change it can grow quite fast. I do not have better short terms idea though.

>> Argument againts strip are mostly, "let's wait for obsolete marker so we do not
>> have to resolve the issue ourself". This delay the command by three month. A
>> delay you do not seems to want :-)
> 
> I've been meaning to write an autogc extension for strip-backup for a while. It's not terribly hard, I've just been managing with `find`. I might even try to convince mom that we should just do this by default (clean up after 90d or so).
> 
> In theory, I'd also like an extension that makes restoring from strip-backup less painful. If anyone has thoughts on that, please let me know.

Yes, a lot a thing can be done to improves this. However I will be a bit sad if a lot of effort is put in this direction because reusing the existing revlog mechanism is obviously a more powerful and saner approach mid/long terms.

But, spending a small amount of time to greaty improves the situation is of course a good idea.

>>> - amending merges: should be possible, will not be implemented for now.
>> 
>> +1
>> 
>>> Feel free to raise other unfinished business, patch will be sent sometime
>>> next week.
>> 
>> I've worked a bit on the amend concept for the evolve extension. It may be a
>> good idea to meet in order to join our effort.
> 
> I think that --amend is a core enough thing (how many of us have an 'hg-amend' shell alias that uses mq?) that it makes sense to try and get it in separate from the larger-scope evolution, but they should definitely share the mechanism for marking old changes as obsolete.

Seems likes you got me wrong. A very little differs for amend mechanism based on strip or obsolete. In practice, nothing should be different except one of the very last call used to discard the rewritten changese:  "strip(<old>)" vs "obsolete([<new>], <old>)".

I'm talking about collaborating on the mechanism itself.

* How the version is evolve have mutated from the series sentlast year and what mutation could be reused?
* How to build the mechanism so it is easy for another command (extension?) to use it

-- 
Pierre-Yves David