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

[Martin Geisler]

Pierre-Yves David <pierre-yves.david at logilab.fr> writes:

> On Mon, Feb 20, 2012 at 02:02:30PM +0200, Idan Kamara wrote:
>> On Mon, Feb 20, 2012 at 8:47 AM, Martin Geisler <mg at lazybytes.net> wrote:
>> >
>> > Idan Kamara <idankk86 at gmail.com> writes:
>> >
>> > > On Sat, Feb 18, 2012 ayyt 12:05 AM, Matt Mackall <mpm at selenic.com> wrote:
>> > >> I don't think launching and quitting an editor is overly burdensome,
>> > >> especially given that fixing a commit message will be an extremely
>> > >> common usage.
>
> I'm using "amend" very often and I think having to manually validate they commit
> message is burdensome. It is equivalent to have a confirmation prompt every
> time your want to.
>
>     "You are going to amend. type ':x' to proceed"
>
> So I better not have an editor popped by default. If people prefer to have the
> editor popped by default, I think we need a kind of '-M --reuse-message' switch
> does not pop and editor.
>
> So we will have a switch to control editor on way or another.
>
> The ability to refresh the commit message in an editor is a must have. It was
> on of the first thing I added to the amend command of the experimental evolve
> extension. Working around it with -m and -l was very painful.
>
>> > > I agree. And even if we end up having to choose between:
>> > >
>> > > 1) adding a new command
>> > > 2) adding --edit to commit
>> > >
>> > > I think 2) is preferable.
>
> I prefer (1) for reason explained before (addition switch now, additional switch
> later, different semantic). (But won't fight to death for it)
>
>> > Same goes for -U and -D.
>> >
>> > I never use the -U and -D options for qrefresh and I don't even think
>> > the --amend flag for commit should support it. Ammend means "redo the
>> > very last commit" and so the user and date is already given by "this
>> > user" and "now".
>> 
>> I never use them either but the impression I got from most commands
>> with similar behavior to --amend is that they preserve the old
>> date/user and have an option to refresh those.
>> 
>> So in my opinion we should keep the old date/user by default and
>> add -U/-D later on if there's enough need (rather than doing the opposite
>> and end up adding --keep-user/date).
>
> I agree with Idan here, we should keep the old values by default and add option to refresh them.
>
> A interesting parallel can be done about the commit message. It would be
> consistent to we keep it as is by default and add a switch to update it?
>
> Note: I strongly disagree with the following statement from Martin
>
>     Amend means "redo the very last commit"
>
> This **may** be a short-term implementation limitation but it is
> semantically wrong. Such implementation limitation will not last long.

I don't think it's "semantically wrong" if your semantics is:

  hg commit --amend == hg rollback; hg commit

That's how I've thought of that hypothetical flag from the beginning.

I actually don't care much if it's a command or a flag, I'm just saying
that I find it natural that a flag on *commit* would behave as rollback
plus a new commit (with updated timestamp, of course).

>> > In that way, 'hg commit --amend' becomes very much like
>> >
>> >  hg rollback; hg commit -l .hg/last-message.txt
>> >
>> > with the twist that the editor is started even though a commit
>> > message is given on the command line.
>> 
>> Sometimes you might be doing several commits and only when you're
>> about to push you review them and realize you've made a mistake.
>> 
>> So I think it's also useful to amend a changeset with children (and
>> then manually rebasing those to the amended commit, which raises the
>> question whether rebase preserves date/user, and it turns out it
>> does).
>
> +1: The ability to amend an arbitrary commit is very useful. The amend
> + rebase combo is a big improvement over mq in terms of conflict
> handling[1].

I'm not saying it isn't useful. It's clear that it's very useful. Being
able to edit changesets further back than the very last changeset is so
useful that we're willing to use mq and other extensions to do so.

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://www.aragost.com/mercurial/customer-projects/