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

[Augie Fackler]

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.

> 
> 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.

>> - 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.

> 
> 
> -- 
> Pierre-Yves David
> 
> http://www.logilab.fr/
> 
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel