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

[Pierre-Yves David]

Last week discussion on IRC and recent email convince me to argue event
stronger to use a dedicated command.

The main argument to add an --amend switch on commit is "This is a simple
solution to a simple problem". But I don't feel we can stop there. I strongly
believe a big part of mercurial success account for:

    1) we provide simple solution to simple problem,
    2) we provide powerful to complex problem (and as simple as possible),
    3) we provide the two options in a consistent way.

Of course iterative work is a good idea. We should do "(1) simple solution"
before doing "(2) powerful solution" but to ensure "(3) consistency" we need to
Think about (2) before freezing (1).

Let's go back to our amend usecase:

(1) We want a simple and clean alternative to:

    $ hg commit
    $ touch <file>
    $ hg rollback
    $ hg commit -m "the same message I preserved somehow"

    You suggest to introduce.

    $ hg commit
    $ touch <file>
    $ hg commit --amend

    MISSION ACCOMPLISHED. We have a simple solution a simple problem.

    But what about the futur?

(2) But this new feature is a small step in the direction of a critical history
    rewriting operation: "update a changeset". In other words you are moving
    toward a full featured emplacement to mq's qrefresh.

    To easily solve more situation (and send qrefesh back in the abyss)  you'll
    probably just need an handful of additional switches. And you **will** have to
    add them as some point. Plug the amend machinery on commit mean that
    those additional switches need to be added to commit too. This is bad idea and
    several useful switches will probably be rejected not to clutter commit.

    Here is some-example of switches.

    /!\ You do not need to read them if you are already convinced that a new
    /!\ behavior need new variant.


    --edit      Update the commit message.

                Spawning an editor every time you want to refresh a changeset
                content seems wrong to me. I'm using qrefresh and hg amend far
                very often. This need to be a fast a cheap operation. It should
                not requires you to fight with your editor everytime.

                Even if spawning an editor is picked as the default. I expect a
                --keep-message switch to appear.

                Such flag are -required- for amend  but do not make sense for
                commit.

                (git have this on commit mainly for amend purpose)

    -D and -U   qrefresh have option to update the date of a commit to the
                current one and to get the ownership a refreshed commit. People
                will want to keep them when moving away from mq. But I'm pretty
                sure they won't make it as commit switch.

                (git have a --reset-author switch on commit for this purpose)

    --rebase    Once amending a changeset with children will be valid (when
                obsolete is done), people will want a "all in one" operation
                that both amend the changeset and resync descendant changesets
                (think about pull --rebase).

                Such switch don't make sense on commit (or sense I do not want
                to encourage)

                (note: amending a changeset with children may motivate a
                --force switch.)

                (git is unable to handle such detached commit situation)

    --force     amend changeset with descendant (see above)

    --???       option to exclude content already present in previous commit version

                (1) commit file A and B.
                (2) I update B and C
                (3) I want to amend into a commit containing A and C only
                      (change in B goes back to working directory).

                note: Step (3) can currently be done using:

                    * rollback: hg rollback; hg commit A C

                    * qrefresh as "hg qrefresh A C" or "hg qrefresh -sX B C"

                I expect it to a very common need. Committing too much changes at
                the same time is a very common mistake.

                This is different from -X exclude or explicit inclusion because
                it works for already committed changeset, not just dirty working
                directory. The original commit command does not need this
                distinction.

                (git have the staging area to handle this (If I understand it
                properly))

    --note      This is expected to be introduce by obsolete for every history
                rewriting operation. It will be a comment of why a changeset is
                rewritten. The data is stored in obsolete internal and available
                for people who tries to understand what is happening.

                Commit is not a rewriting operation an will not get this option.

                (git does not have concept near the obsolete one)

    I'll stop there. I think this example corpus is convincing enough that
    amend operation will eventually need dedicated flags that does not belong to
    commit.

(3) As explained explained above, the amend concept **will** most certainly need
    additional option and flagging. If amend operation is available through a
    commit flag we have two solution to extend it:

    A) Add flag to commit which are not related to what commit does.

    B) Introduce a new command that finish the job.

    Both solutions leads to inconsistent UI.

    I do not think we can elude the issue now as this **will** happen. That is
    why I advocate a "do it right the first time" approach: Adding a new command
    for amend from the beginning.


This a good example of what I meant by "let's be careful". Adding amend
mechanism is a good idea. Let's first draw a generic plan for history rewriting,
Then ensure this amend idea fit well in the generic view. And finally implement
this amend step. If we do it the other way, I expect frustration in a few month.

Cheer.

-- 
Pierre-Yves David

http://www.logilab.fr/

-------------- 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/20120213/bee0e022/attachment.asc>