hg resolve

[Peter Arrenbrecht]

On Fri, Dec 19, 2008 at 10:01 PM, Matt Mackall <mpm at selenic.com> wrote:
> On Fri, 2008-12-19 at 10:07 +0100, Peter Arrenbrecht wrote:
>> On Thu, Dec 18, 2008 at 6:26 PM, Matt Mackall <mpm at selenic.com> wrote:
>> > On Fri, 2008-12-12 at 15:31 -0800, Peter Loron wrote:
>> >> On Dec 10, 2008, at 4:36 PM, TK Soh wrote:
>> >>
>> >> > On Wed, Dec 10, 2008 at 3:54 PM, Peter Arrenbrecht
>> >> > <peter.arrenbrecht at gmail.com> wrote:
>> >> >> On Wed, Dec 10, 2008 at 11:11 AM, Leslie P. Polzer
>> >> >> <sky at viridian-project.de> wrote:
>> >> >>> Second issue, related: resolve without any arguments will
>> >> >>> just overwrite a fixed conflict, discarding any changes
>> >> >>> made.
>> >> >>>
>> >> >>> It should warn/ask the user interactively whether they
>> >> >>> really want to do that. Alternative: no default behaviour
>> >> >>> at all and a new switch that will restore the original
>> >> >>> conflicts.
>> >> >>
>> >> >> +1. This has bitten me more than once, too. But maybe it's too late
>> >> >> for removing the default (backward compat rules).
>> >> >
>> >> > If the rules have to be broken, it's better to do it while 1.1 is
>> >> > still 'warm'.
>> >>
>> >> +2  This would be a very good change.
>> >
>> > Sorry, you only get one vote.
>> >
>> > We plan to add a new -a switch analogous to revert's.
>>
>> But no change to the default behaviour, meaning `hg resolve the/file`
>> will clobber any manual resolving I've already done when I meant to
>> say `hg resolve -m the/file`?
>
> Yes. 'resolve' is a English verb. If you 'resolve a problem', you're not
> 'marking a problem as solved', you are 'taking steps to solve a
> problem'.
>
> Which is why the svn command is in the past tense: 'I've already fixed
> it'. As far as I know, svn doesn't have a built-in concept of helping
> you fix it by launching a tool with all the appropriate versions.

Indeed. Only I think the part of this that Hg does for me is not the
"resolving", but the "merging" (or, even more precisely, "atttempt at
automated merging"). Witness this line emitted by `hg merge`:

  1 files updated, 1 files merged, 0 files removed, 2 files unresolved

When I get this, the unresolved files already contain the best attempt
Hg could make: clean cases are merged, conflicts are flagged. Maybe
I'm missing something here, but for me, there is no difference in tool
choice between `hg merge` and `hg resolve`. So I don't see how `hg
resolve` should use a different term than `hg merge`.

Given such conflicts, it's now my turn. I go and resolve the
conflicts. So "resolve" is what I do, not Hg. Which leads me to think
a command set such as

  hg resolved  --  marks a file as cleanly merged
  hg resolved -u -- marks as unresolved
  hg resolved -l -- lists conflict resolution states of files
  hg remerge  --  retries a clean merge on the given file(s), or --all

would be more consistent and lead to less unfortunate surprises.

And, though this is debatable, we could say that `hg merge`, when
called with an uncommitted merge, is equivalent to `hg resolved -l`,
albeit with a hint that this is an existing uncommitted merge.

>
> The current default behavior is precisely the one people have asked for:
> "I did a merge wrong and something broke and I want to try it again".
> Fewer people asked for "show me a list of files that still need
> merging" (resolve -l). And I'm pretty sure no one ever said "hey, can we
> have svn's resolved command?" I didn't even know it existed until
> recently and if I had, I would have chosen a different name.
>
> Further, if you're doing:
>
> hg merge
> emacs foo.c  # sort out conflict markers or otherwise manually merge
> hg resolve -m foo.c
>
> ..you're making more work for yourself. You're supposed to be doing:
>
> hg merge
> hg resolve foo.c  # use a merge tool

This is where you lose me. On my machine, merge and resolve don't use
different tools. Both try the internal merge, then launch meld if
there are conflicts.

> The slow path exists and is allowed, of course, but I'm not going to
> make the common fast path harder to make the slow path easier.

-parren