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

Kevin Bullock kbullock+mercurial at ringworld.org
Wed Feb 22 18:06:24 UTC 2012


On Feb 21, 2012, at 11:18 AM, Pierre-Yves David wrote:

> On Tue, Feb 21, 2012 at 12:18:05PM +0200, Idan Kamara wrote:
>> On Mon, Feb 20, 2012 at 6:29 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>>> 
>>> On Mon, 20 Feb 2012 17:19:44 +0100
>>> Jason Harris <jason at jasonfharris.com> wrote:
>>>> 
>>>> To the user, the amend part is really associated with commit. It's doing
>>>> the
>>>> same thing.
> 
> I still disagree on this point. From the user point of view:
> 
>    "commit" *create* a new changeset.
> 
>    "amend"  *update* the content of an existing changeset.
> 
> This is not the same thing at all.
> 
> qnew != qrefresh
> commit != amend

This analogy is faulty. The word "commit" does _not_ imply creating anything new; it indicates saving what's already present (which could apply equally to creating a new change set or updating the current one). The command 'qnew', by contrast, contains the word "new" right inside it.

It's thus perfectly clear from the terms used what the following two operations would do:

$ hg commit # save what I've got
$ hg commit --amend # save what I've got by updating what I saved before

If we eventually want to have a more powerful 'amend' command that can do something besides just updating the working dir parent (and only if said parent is a head!), then 'commit --amend' becomes a perfectly cromulent shorthand for 'amend .' or whatever, similarly to the way that pull --update is shorthand for pull && update.

pacem in terris / мир / शान्ति / ‎‫سَلاَم‬ / 平和
Kevin R. Bullock

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-devel/attachments/20120222/c42521d5/attachment-0002.html>


More information about the Mercurial-devel mailing list