[PATCH RFC] commit: add --amend option to amend the parent changeset
pierre-yves.david at logilab.fr
Fri Feb 24 11:55:58 CST 2012
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)
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.
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 :-)
> - 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: Digital signature
More information about the Mercurial-devel