[PATCH RFC] commit: add --amend option to amend the parent changeset
pierre-yves.david at logilab.fr
Mon Feb 20 07:50:18 CST 2012
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.
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.
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.
 And this is in fact the first step to deprecated the use of MQ in most situation.
 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...
Size: 198 bytes
Desc: Digital signature
More information about the Mercurial-devel