[PATCH RFC] commit: add --amend option to amend the parent changeset
pierre-yves.david at ens-lyon.org
Fri Feb 24 17:54:09 CST 2012
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
>> 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.
>>> 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
More information about the Mercurial-devel