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

[Pierre-Yves David]

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.


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

This the first operation I started to play with when experimenting around
replacing mq. But after using this experimental amend a few months without
obsolete marker, I can report that resulting graph can become quite hairy to
handle even with the support a visual tool[2].

I'm not saying we shouldn't support this use case. But we better neither export
or encourage such usage until we have a proper UI to handle the situation.

Obsolete marker will improve the situation a lot with clear information about
which part should be rebase, and where it should be rebased and even automatic
stabilization of the situation.




-- 
Pierre-Yves David

http://www.logilab.fr/

[1] And this is in fact the first step to deprecated the use of MQ in most situation.

[2] One of the main source of complexity are the temporary graph structure you
    have to deal with during conflict.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-devel/attachments/20120220/e4488ea0/attachment.asc>