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

Idan Kamara idankk86 at gmail.com
Mon Feb 20 06:02:30 CST 2012


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 at 12:05 AM, Matt Mackall <mpm at selenic.com> wrote:
> >>
> >> On Fri, 2012-02-17 at 18:44 +0100, Patrick Mézard wrote:
> >> > Le 02/02/12 13:55, Idan Kamara a écrit :
> >> > > On Thu, Feb 2, 2012 at 2:45 PM, Angel Ezquerra <
> > angel.ezquerra at gmail.com <mailto:angel.ezquerra at gmail.com>> wrote:
> >> > >
> >> > >     On Thu, Feb 2, 2012 at 1:35 PM, Idan Kamara
> >> > > <idankk86 at gmail.com<mailto:idankk86 at gmail.com>> wrote:
> >> > >     > # HG changeset patch
> >> > >     > # User Idan Kamara <idankk86 at gmail.com
> >> > > <mailto:idankk86 at gmail.com>>
> >> > >     > # Date 1328185747 -7200
> >> > >     > # Branch stable
> >> > >     > # Node ID cc7dec00d5016f03acf789c35ce6ef50b204f0cb
> >> > >     > # Parent  0620421044a2bcaafd054a6ee454614888699de8
> >> > >     > commit: add --amend option to amend the parent changeset
> >> >
> >> > [...]
> >> >
> >> > >
> >> > >     This is quite cool and a neat example of what can be done now
> >> > >     that mercurial tracks phases :-)
> >> > >
> >> > >     One thing that would be nice is to be able to just "amend"
> >> > >     the commit message (without modifying the patch file
> >> > >     contents). I think _that_ is probably _the_ most commonly
> >> > >     requested history editing operation (at least in my
> >> > >     experience).
> >> > >
> >> > >
> >> > > Right. I didn't take care of that yet and due to the current
> >> > > implementation it fails with a 'nothing changed' message. But it
> >> > > should be doable.
> >> >
> >> > I think the UI for this should be addressed right away. What are
> >> > the choices?
> >> >
> >> > 1- git commit --amend: open the editor with the current message all
> >> > the time, even when the working directory is clean
> >> > 2- Add qrefresh like --edit option
> >>
> >> 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 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. 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).

>
> 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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20120220/b09eeb45/attachment.html>


More information about the Mercurial-devel mailing list