[PATCH] backout: add --commit option

[FUJIWARA Katsunori]

At Wed, 17 Dec 2014 17:40:22 -0800,
Pierre-Yves David wrote:
> 
> 
> 
> On 12/17/2014 05:39 PM, Mateusz Kwapich wrote:
> > # HG changeset patch
> > # User Mateusz Kwapich <mitrandir at fb.com>
> > # Date 1418865972 28800
> > #      Wed Dec 17 17:26:12 2014 -0800
> > # Node ID aa4f1fa1bab5dca4848eeaea36ca5485994fc4f2
> > # Parent  495bc1b65d25872324a0220354f048b220304bd1
> > backout: add --commit option
> >
> > Mercurial backout command makes a commmit by default only when the backed out
> > revision is the parent of working directory and doesn't commit in any other
> > case.
> >
> > The --commit option changes behaviour of backout to make a commit whenever
> > possible (i.e. there is no unresolved conflicts). This behaviour seems more
> > intuitive to many use (especially git users migrating to hg).
> 
> +1 I was looking for such flag a few hours ago.

I was just asked by an user why "hg merge" doesn't have the
functionality to commit soon after successful merging.

I answered that:

  - Mercurial policy is "one functionality for one command"

    "branch merge, don't forget to commit" reminder message after "hg
    merge" should navigate users, too.

  - the result of merging should be confirmed before committing

    "successful merging" ensures that file contents are merged
    mechanically (if using "internal:merge") without conflicts, but
    not that they are merged correctly in semantics view.
    
  - TortoiseHg can navigate users to commit just after merging, if no
    conflict is detected.

I myself like current separation between "merge" and "commit". But it
is fact that some users want "hg merge" to commit automatically if no
conflict is detected (may "--commit" of "git merge" make this trend ?)

I listed up revision creation and internal merging of each commands
for reference.

  - commands creating single revision

    - "backout" for other than current parent (regardless of
      "--merge"), "merge"

      These imply (internal) merging, and user should "hg commit"
      manually.

      Mateusz plans allowing "backout" without "--merge" to commit new
      revision in this case.

    - "backout" for current parent, "tag"

      These don't imply internal merging, and new revision is created
      automatically.

  - commands creating multiple revisions

    - "bundle", "import", "pull"

      These don't imply internal merging, and new revisions are
      created automatically.

    - "graft", "histedit", "rebase", "transplant" without "--merge"

      These imply internal merging, but new revisions are committed
      automatically if no conflict is detected.

    - "fetch" for another anonymous head

      This implies (internal) merging. Merging revision is committed
      automatically, if no conflict is detected.

    - "transplant" with "--merge"

      This doesn't imply internal merging, even though merging
      revision is created: files in the working directory are changed
      by patch-ing. And new revisions are created automatically.


At first, I don't disagree with adding "--commit" itself. I just want
to clarify about command policy around (internal) merging before
adding it.

Regardless of "--merge" option, "backout" should create same
(internal) merging result from the point of view of file contents,
shouldn't it ?

Then, are there any reason that merging result isn't automatically
committed in the case of "backout --merge --commit" ? because of
"creating new topological branch" ?  (or just forgot ? > Mateusz)

If "backout --merge --commit" is allowed to commit merging revision
automatically, what about adding "--commit" to "hg merge" ?
Correctness of internal merging shouldn't be so different between
"backout --merge" and "merge".


BTW, it seems to be reasonable that "automated committing" commands
commit revisions merging internally without user interactions, because
user interactions decrease convenience of automation, even though
internal merging doesn't ensure correctness in semantics view also in
this case :-)

> -- 
> Pierre-Yves David
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel

----------------------------------------------------------------------
[FUJIWARA Katsunori]                             foozy at lares.dti.ne.jp