[PATCH 4 of 4] subrepo: show detailed revision info for the divergent subrepo revisions

[Angel Ezquerra]

On Sat, May 17, 2014 at 1:16 AM, Matt Mackall <mpm at selenic.com> wrote:
> On Thu, 2014-05-08 at 00:54 +0200, Angel Ezquerra wrote:
>> # HG changeset patch
>> # User Angel Ezquerra <angel.ezquerra at gmail.com>
>> # Date 1399415105 -7200
>> #      Wed May 07 00:25:05 2014 +0200
>> # Node ID dd02d8d8c7d244755e98c4b656b6eefedd668b98
>> # Parent  874013facd42bd2a8bbd07634cad02448709c5ac
>> subrepo: show detailed revision info for the divergent subrepo revisions
>
>>     subrepository sub diverged (local revision: b2fdb12cd82b, remote revision: aa037b301eba)
>> +  subrepository sub local revision details:
>> +  changeset:   0:b2fdb12cd82b
>> +  user:        test
>> +  date:        Thu Jan 01 00:00:00 1970 +0000
>> +  summary:     0sub
>> +
>> +  subrepository sub remote revision details:
>> +  changeset:   1:aa037b301eba
>> +  tags:        tip
>> +  user:        test
>> +  date:        Thu Jan 01 00:00:00 1970 +0000
>> +  summary:     foo
>> +
>>    (M)erge, keep (l)ocal or keep (r)emote? m
>
> I'm afraid I'm not keen on this.

First, I want to thank you for the detailed explanation for your
rejection of this patch. Please let me make some comments below.

> First, it's WAY more verbose than any other prompt, but perhaps not
> verbose enough to actually accomplish its purpose. I will often probably
> still need to go investigate the subrepo DAG if I'm in doubt.

The existing prompt (which I introduced) has proven (in my use) to not
be very helpful. It is great that you can now stop mercurial from
merging a subrepo, but it is hard to choose which subrepo revision to
keep unless you plan for it in advance (before doing the merge). In
some cases this proposed prompt would not contain enough information
to choose the right revision, but in my experience it would be enough
in a lot of cases. For example we mostly use tagged subrepo revisions.
If you do that and you follow a sane tag naming policy choosing the
right revision would be quite easy in most cases.

That being said I agree that this is more verbose than most other
prompts. The only alternative that I thought of that was much less
verbose (and would also be very useful in dealing with subrepo merge
conflicts) was to let the user know if one of the subrepo revisions is
a descedant of the other (since in most cases you'd want to keep the
descendant). I had planned to send a follow up patch adding that piece
of information.

> Second, I could do that before this patch anyway: just open another
> terminal, cd into the subrepo, and ask about the revisions.

When you are using the command line it is possible to do as you say.
However, when using TortoiseHg that is not so easy. We convert
mercurial's prompts into modal dialogs. When this dialog is shown the
user cannot view the offending subrepo DAG unless he manually opens a
new workbench. I considered parsing this prompt and adding the info
into our modal dialog on the TortoiseHg side but I thought it was best
to deal with this on the mercurial side instead (for the benefit of
command line users).

> But more importantly, my plan for merge prompts is "no more". There are
> a bunch of merge decisions that are really hard to deal with via prompts
> (like case collisions) and rather than try to deal with them via
> prompts, I want to instead say "hey, we hit this merge problem, see
> resolve". As part of this, I want to allow deferring all the existing
> prompts to resolve as well so that they can be retried or manually
> resolved. So this is moving in the wrong direction: try to do more with
> prompts.

This is a great plan and I am all for it. However, if your plan is
remove all merge prompts, does it really matter whether the prompts
that will be removed are more or less verbose when they are removed?
Unless the plan is to remove all prompts for mercurial 3.1, I don't
see a reason to not improve the existing prompts until they are
removed.

So, if the merge prompt removal is not for 3.1, would you accept a
revised version of this patch series that:

- Showed the tags on the subrepo revisions (if any)
- Indicated when one of the subrepo revisions descends from the other
(if that is the case).

I think those two changes would be a big improvement over the existing prompt.

Thinking about a future in which there are no more merge prompts and
everything is resolved after the fact, how do you envision people
would resolve a subrepo conflict? Would hg resolve show this kind of
prompt when resolving a subrepo? or perhaps it would show more
detailed info, even a part of the subrepo DAG? We could perhaps make
hg diff subrepo aware and show info similar to the info that
TortoiseHg shows when a subrepo has changed on a given revision.

Cheers,

Angel