--all to guard 'hg resolve' from mis-operation

[FUJIWARA Katsunori]

At Wed, 17 Dec 2008 13:43:23 +0200,
Giorgos Keramidas wrote:
> 
> On Wed, 17 Dec 2008 08:54:34 +0100, "Dirkjan Ochtman" <dirkjan at ochtman.nl> wrote:
> > On Wed, Dec 17, 2008 at 07:20, FUJIWARA Katsunori <fujiwara at ascade.co.jp> wrote:
> >> I think that '--all' should be introduced into 'hg resolve' like as
> >> 'hg revert' to guard from mis-operation, at least for '-m'/'-u' and
> >> re-merge(no-opt).
> >
> > I think this is a good idea. Is this recent enough that we can change
> > it like this?
> 
> I like the idea too, but a bit of extra thought may be nice, to avoid
> changing this yet again after a short time.

Thank you for your comments about my idea.

> Right now the default behavior of `hg merge' is to resolve all the files
> if there are conflicts.  How would the new --all option interact with
> the case of merges that currently spawn a resolve run automatically?
> 
> Should `hg merge' be changed to inhibit auto-resolution when we add the
> --all option?  I think it would make sense to do that, and change the
> default behavior of "hg merge" to do something like:
> 
>     [1] Try to auto-merge
> 
>     [2] If a resolve would be needed, keep resolving files but mark the
>         merge as 'incomplete'
> 
>     [3] When all files from the two heads have been merged, check if the
>         merge is 'incomplete'
> 
>     [4] If yes, then display a message like:
> 
>           > hg up -C head1
>           > hg merge
>           9 files updated, 0 files merged, 0 files removed, 5 files unresolved
>           (run "hg resolve --all" or "hg resolve FILE" to complete the merge)

And please let me confirm your suggestion in my words, because I'm not
good at English.

    (A) You want to prevent `hg merge' from:
        (A-1) nothing (= current behavior)
        (A-2) resolving confliction of each changesets
        (A-3) merging(= including modification from) both changesets

You seem to describe (A-2), so:

    (B) You want `hg merge' to merge each changesets into the file, if
        there is no confiliction between them for it. and

    (C) just after `hg merge', there is no file which includes
        confliction marks(<<<<, >>>>) in it, if we use `diff3' as
        merge tool

        GUI is not invoked, if merge-tools.xxxx.premerge is True.

If so, it looks good for me, too. Role separaion is clear.

But is there anybody who wants `hg merge' to behave as similarly as
now ?  or does he want `--resolve' option to `hg merge' instead of
change of its behavior ?

I can see faces of who want so around my desk :-)

> Maybe something like the following patch?

    (D) this does not include (A-2) feature, so

    (E) invocation of merge.update(or its implementation) should be
        changed

> diff -r 4acf5f24912b mercurial/hg.py
> --- a/mercurial/hg.py	Mon Dec 15 12:03:28 2008 -0800
> +++ b/mercurial/hg.py	Wed Dec 17 13:42:28 2008 +0200
> @@ -273,7 +273,7 @@
>      stats = _merge.update(repo, node, True, force, False)
>      _showstats(repo, stats)
>      if stats[3]:
> -        repo.ui.status(_("use 'hg resolve' to retry unresolved file merges\n"))
> +        repo.ui.status(_("use 'hg resolve --all' or 'hg resolve FILE' to retry unresolved file merges\n"))
>      elif remind:
>          repo.ui.status(_("(branch merge, don't forget to commit)\n"))
>      return stats[3] > 0
> %%%

----
[FUJIWARA Katsunori]/fujiwara at ascade.co.jp(foozy at lares.dti.ne.jp)