Patchwork merge: let the user choose to merge, keep local or keep remote subrepo revisions

login
register
mail settings
Submitter Angel Ezquerra
Date Sept. 7, 2013, 5:09 a.m.
Message ID <15548e5b1c00bd2f261e.1378530572@ubuntu>
Download mbox | patch
Permalink /patch/2398/
State Superseded
Commit 5e10d41e7b9cffe99ab798c066038518ec51e494
Delegated to: Kevin Bullock
Headers show

Comments

Angel Ezquerra - Sept. 7, 2013, 5:09 a.m.
# HG changeset patch
# User Angel Ezquerra <angel.ezquerra@gmail.com>
# Date 1378420708 -7200
#      Fri Sep 06 00:38:28 2013 +0200
# Node ID 15548e5b1c00bd2f261e3c81d39f2465263bc3c3
# Parent  1d07bf106c2ad1c7ef5e257e754ca8d858bd04b0
merge: let the user choose to merge, keep local or keep remote subrepo revisions

When a subrepo has changed on the local and remote revisions, prompt the user
whether it wants to merge those subrepo revisions, keep the local revision or
keep the remote revision.

Up until now mercurial would always perform a merge on a subrepo that had
changed on the local and the remote revisions. This is often inconvenient. For
example:

- You may want to perform the actual subrepo merge after you have merged the
parent subrepo files.
- Some subrepos may be considered "read only", in the sense that you are not
supposed to add new revisions to them. In those cases "merging a subrepo" means
choosing which _existing_ revision you want to use on the merged revision. This
is often the case for subrepos that contain binary dependencies (such as DLLs,
etc).

This new prompt makes mercurial better cope with those common scenarios.

Notes:

- The default behavior (which is the one that is used when ui is not
interactive) remains unchanged (i.e. merge is the default action).
- This prompt will be shown even if the ui --tool flag is set.
- I don't know of a way to test the "keep local" and "keep remote" options (i.e.
to force the test to choose those options).
Martin Geisler - Sept. 7, 2013, 11:46 p.m.
Angel Ezquerra <angel.ezquerra@gmail.com> writes:

> # HG changeset patch
> # User Angel Ezquerra <angel.ezquerra@gmail.com>
> # Date 1378420708 -7200
> #      Fri Sep 06 00:38:28 2013 +0200
> # Node ID 15548e5b1c00bd2f261e3c81d39f2465263bc3c3
> # Parent  1d07bf106c2ad1c7ef5e257e754ca8d858bd04b0
> merge: let the user choose to merge, keep local or keep remote subrepo revisions
>
> When a subrepo has changed on the local and remote revisions, prompt
> the user whether it wants to merge those subrepo revisions, keep the
> local revision or keep the remote revision.
>
> Up until now mercurial would always perform a merge on a subrepo that
> had changed on the local and the remote revisions. This is often
> inconvenient. For example:
>
> - You may want to perform the actual subrepo merge after you have
> merged the parent subrepo files.
>
> - Some subrepos may be considered "read only", in the sense that you
> are not supposed to add new revisions to them. In those cases "merging
> a subrepo" means choosing which _existing_ revision you want to use on
> the merged revision. This is often the case for subrepos that contain
> binary dependencies (such as DLLs, etc).
>
> This new prompt makes mercurial better cope with those common
> scenarios.
>
> Notes:
>
> - The default behavior (which is the one that is used when ui is not
> interactive) remains unchanged (i.e. merge is the default action).
> - This prompt will be shown even if the ui --tool flag is set.
> - I don't know of a way to test the "keep local" and "keep remote"
> options (i.e. to force the test to choose those options).
>
> diff -r 1d07bf106c2a -r 15548e5b1c00 mercurial/subrepo.py
> --- a/mercurial/subrepo.py	Wed Sep 04 18:42:55 2013 -0700
> +++ b/mercurial/subrepo.py	Fri Sep 06 00:38:28 2013 +0200
> @@ -201,9 +201,24 @@
>                  wctx.sub(s).get(r, overwrite)
>                  sm[s] = r
>              else:
> -                debug(s, "both sides changed, merge with", r)
> -                wctx.sub(s).merge(r)
> -                sm[s] = l
> +                debug(s, "both sides changed")
> +                option = repo.ui.promptchoice(
> +                    _(' subrepository %s diverged (local revision: %s, '
> +                      'remote revision: %s)\n'
> +                      '(M)erge, keep (l)ocal or keep (r)emote?'
> +                      '$$ &Merge $$ &Local $$ &Remote')
> +                    % (s, l[1][:12], r[1][:12]), 0)

I can see in the tests that one can answer "m" to this prompt, but the
"(M)erge" suggests to me that I should answer "M". I quickly checked the
other prompts and I think all the other options are in lowercase.
Angel Ezquerra - Sept. 8, 2013, 12:07 a.m.
On Sun, Sep 8, 2013 at 1:46 AM, Martin Geisler <martin@geisler.net> wrote:
> Angel Ezquerra <angel.ezquerra@gmail.com> writes:
>
>> # HG changeset patch
>> # User Angel Ezquerra <angel.ezquerra@gmail.com>
>> # Date 1378420708 -7200
>> #      Fri Sep 06 00:38:28 2013 +0200
>> # Node ID 15548e5b1c00bd2f261e3c81d39f2465263bc3c3
>> # Parent  1d07bf106c2ad1c7ef5e257e754ca8d858bd04b0
>> merge: let the user choose to merge, keep local or keep remote subrepo revisions
>>
>> When a subrepo has changed on the local and remote revisions, prompt
>> the user whether it wants to merge those subrepo revisions, keep the
>> local revision or keep the remote revision.
>>
>> Up until now mercurial would always perform a merge on a subrepo that
>> had changed on the local and the remote revisions. This is often
>> inconvenient. For example:
>>
>> - You may want to perform the actual subrepo merge after you have
>> merged the parent subrepo files.
>>
>> - Some subrepos may be considered "read only", in the sense that you
>> are not supposed to add new revisions to them. In those cases "merging
>> a subrepo" means choosing which _existing_ revision you want to use on
>> the merged revision. This is often the case for subrepos that contain
>> binary dependencies (such as DLLs, etc).
>>
>> This new prompt makes mercurial better cope with those common
>> scenarios.
>>
>> Notes:
>>
>> - The default behavior (which is the one that is used when ui is not
>> interactive) remains unchanged (i.e. merge is the default action).
>> - This prompt will be shown even if the ui --tool flag is set.
>> - I don't know of a way to test the "keep local" and "keep remote"
>> options (i.e. to force the test to choose those options).
>>
>> diff -r 1d07bf106c2a -r 15548e5b1c00 mercurial/subrepo.py
>> --- a/mercurial/subrepo.py    Wed Sep 04 18:42:55 2013 -0700
>> +++ b/mercurial/subrepo.py    Fri Sep 06 00:38:28 2013 +0200
>> @@ -201,9 +201,24 @@
>>                  wctx.sub(s).get(r, overwrite)
>>                  sm[s] = r
>>              else:
>> -                debug(s, "both sides changed, merge with", r)
>> -                wctx.sub(s).merge(r)
>> -                sm[s] = l
>> +                debug(s, "both sides changed")
>> +                option = repo.ui.promptchoice(
>> +                    _(' subrepository %s diverged (local revision: %s, '
>> +                      'remote revision: %s)\n'
>> +                      '(M)erge, keep (l)ocal or keep (r)emote?'
>> +                      '$$ &Merge $$ &Local $$ &Remote')
>> +                    % (s, l[1][:12], r[1][:12]), 0)
>
> I can see in the tests that one can answer "m" to this prompt, but the
> "(M)erge" suggests to me that I should answer "M". I quickly checked the
> other prompts and I think all the other options are in lowercase.

Martin,

thanks for reviewing this patch.

I hesitated when deciding the case for that option. The description
example given on the ui.promptchoice method docstring seems to suggest
that the default option should be capitalized:

"would you like fries with that (Yn)? $$ &Yes $$ &No"

That being said I also saw that most (if not all) other prompts do not
follow that advice and usually are all lowercase, so I would not mind
changing it for consistency's sake.

Cheers,

Angel
Augie Fackler - Sept. 20, 2013, 2:52 p.m.
On Sun, Sep 08, 2013 at 02:07:02AM +0200, Angel Ezquerra wrote:
> On Sun, Sep 8, 2013 at 1:46 AM, Martin Geisler <martin@geisler.net> wrote:
> > Angel Ezquerra <angel.ezquerra@gmail.com> writes:
> >
> >> # HG changeset patch
> >> # User Angel Ezquerra <angel.ezquerra@gmail.com>
> >> # Date 1378420708 -7200
> >> #      Fri Sep 06 00:38:28 2013 +0200
> >> # Node ID 15548e5b1c00bd2f261e3c81d39f2465263bc3c3
> >> # Parent  1d07bf106c2ad1c7ef5e257e754ca8d858bd04b0
> >> merge: let the user choose to merge, keep local or keep remote subrepo revisions
> >>
> >> When a subrepo has changed on the local and remote revisions, prompt
> >> the user whether it wants to merge those subrepo revisions, keep the
> >> local revision or keep the remote revision.
> >>
> >> Up until now mercurial would always perform a merge on a subrepo that
> >> had changed on the local and the remote revisions. This is often
> >> inconvenient. For example:
> >>
> >> - You may want to perform the actual subrepo merge after you have
> >> merged the parent subrepo files.
> >>
> >> - Some subrepos may be considered "read only", in the sense that you
> >> are not supposed to add new revisions to them. In those cases "merging
> >> a subrepo" means choosing which _existing_ revision you want to use on
> >> the merged revision. This is often the case for subrepos that contain
> >> binary dependencies (such as DLLs, etc).
> >>
> >> This new prompt makes mercurial better cope with those common
> >> scenarios.
> >>
> >> Notes:
> >>
> >> - The default behavior (which is the one that is used when ui is not
> >> interactive) remains unchanged (i.e. merge is the default action).
> >> - This prompt will be shown even if the ui --tool flag is set.
> >> - I don't know of a way to test the "keep local" and "keep remote"
> >> options (i.e. to force the test to choose those options).
> >>
> >> diff -r 1d07bf106c2a -r 15548e5b1c00 mercurial/subrepo.py
> >> --- a/mercurial/subrepo.py    Wed Sep 04 18:42:55 2013 -0700
> >> +++ b/mercurial/subrepo.py    Fri Sep 06 00:38:28 2013 +0200
> >> @@ -201,9 +201,24 @@
> >>                  wctx.sub(s).get(r, overwrite)
> >>                  sm[s] = r
> >>              else:
> >> -                debug(s, "both sides changed, merge with", r)
> >> -                wctx.sub(s).merge(r)
> >> -                sm[s] = l
> >> +                debug(s, "both sides changed")
> >> +                option = repo.ui.promptchoice(
> >> +                    _(' subrepository %s diverged (local revision: %s, '
> >> +                      'remote revision: %s)\n'
> >> +                      '(M)erge, keep (l)ocal or keep (r)emote?'
> >> +                      '$$ &Merge $$ &Local $$ &Remote')
> >> +                    % (s, l[1][:12], r[1][:12]), 0)
> >
> > I can see in the tests that one can answer "m" to this prompt, but the
> > "(M)erge" suggests to me that I should answer "M". I quickly checked the
> > other prompts and I think all the other options are in lowercase.
>
> Martin,
>
> thanks for reviewing this patch.
>
> I hesitated when deciding the case for that option. The description
> example given on the ui.promptchoice method docstring seems to suggest
> that the default option should be capitalized:
>
> "would you like fries with that (Yn)? $$ &Yes $$ &No"
>
> That being said I also saw that most (if not all) other prompts do not
> follow that advice and usually are all lowercase, so I would not mind
> changing it for consistency's sake.

If 'm' is the default, then it should be captialized (this is pretty
standard in CLI apps.) The prompt parser should accept both M and m,
as well as L and l etc.

>
> Cheers,
>
> Angel
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel@selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel
Angel Ezquerra - Sept. 20, 2013, 3:19 p.m.
On Fri, Sep 20, 2013 at 4:52 PM, Augie Fackler <raf@durin42.com> wrote:
> On Sun, Sep 08, 2013 at 02:07:02AM +0200, Angel Ezquerra wrote:
>> On Sun, Sep 8, 2013 at 1:46 AM, Martin Geisler <martin@geisler.net> wrote:
>> > Angel Ezquerra <angel.ezquerra@gmail.com> writes:
>> >
>> >> # HG changeset patch
>> >> # User Angel Ezquerra <angel.ezquerra@gmail.com>
>> >> # Date 1378420708 -7200
>> >> #      Fri Sep 06 00:38:28 2013 +0200
>> >> # Node ID 15548e5b1c00bd2f261e3c81d39f2465263bc3c3
>> >> # Parent  1d07bf106c2ad1c7ef5e257e754ca8d858bd04b0
>> >> merge: let the user choose to merge, keep local or keep remote subrepo revisions
>> >>
>> >> When a subrepo has changed on the local and remote revisions, prompt
>> >> the user whether it wants to merge those subrepo revisions, keep the
>> >> local revision or keep the remote revision.
>> >>
>> >> Up until now mercurial would always perform a merge on a subrepo that
>> >> had changed on the local and the remote revisions. This is often
>> >> inconvenient. For example:
>> >>
>> >> - You may want to perform the actual subrepo merge after you have
>> >> merged the parent subrepo files.
>> >>
>> >> - Some subrepos may be considered "read only", in the sense that you
>> >> are not supposed to add new revisions to them. In those cases "merging
>> >> a subrepo" means choosing which _existing_ revision you want to use on
>> >> the merged revision. This is often the case for subrepos that contain
>> >> binary dependencies (such as DLLs, etc).
>> >>
>> >> This new prompt makes mercurial better cope with those common
>> >> scenarios.
>> >>
>> >> Notes:
>> >>
>> >> - The default behavior (which is the one that is used when ui is not
>> >> interactive) remains unchanged (i.e. merge is the default action).
>> >> - This prompt will be shown even if the ui --tool flag is set.
>> >> - I don't know of a way to test the "keep local" and "keep remote"
>> >> options (i.e. to force the test to choose those options).
>> >>
>> >> diff -r 1d07bf106c2a -r 15548e5b1c00 mercurial/subrepo.py
>> >> --- a/mercurial/subrepo.py    Wed Sep 04 18:42:55 2013 -0700
>> >> +++ b/mercurial/subrepo.py    Fri Sep 06 00:38:28 2013 +0200
>> >> @@ -201,9 +201,24 @@
>> >>                  wctx.sub(s).get(r, overwrite)
>> >>                  sm[s] = r
>> >>              else:
>> >> -                debug(s, "both sides changed, merge with", r)
>> >> -                wctx.sub(s).merge(r)
>> >> -                sm[s] = l
>> >> +                debug(s, "both sides changed")
>> >> +                option = repo.ui.promptchoice(
>> >> +                    _(' subrepository %s diverged (local revision: %s, '
>> >> +                      'remote revision: %s)\n'
>> >> +                      '(M)erge, keep (l)ocal or keep (r)emote?'
>> >> +                      '$$ &Merge $$ &Local $$ &Remote')
>> >> +                    % (s, l[1][:12], r[1][:12]), 0)
>> >
>> > I can see in the tests that one can answer "m" to this prompt, but the
>> > "(M)erge" suggests to me that I should answer "M". I quickly checked the
>> > other prompts and I think all the other options are in lowercase.
>>
>> Martin,
>>
>> thanks for reviewing this patch.
>>
>> I hesitated when deciding the case for that option. The description
>> example given on the ui.promptchoice method docstring seems to suggest
>> that the default option should be capitalized:
>>
>> "would you like fries with that (Yn)? $$ &Yes $$ &No"
>>
>> That being said I also saw that most (if not all) other prompts do not
>> follow that advice and usually are all lowercase, so I would not mind
>> changing it for consistency's sake.
>
> If 'm' is the default, then it should be captialized (this is pretty
> standard in CLI apps.) The prompt parser should accept both M and m,
> as well as L and l etc.

That is what I thought from looking at the example in the
ui.promptchoice docstring. I will not send a new version of the patch
then, unless you think there is something else that is worth
improving?

Cheers,

Angel
Augie Fackler - Sept. 20, 2013, 3:20 p.m.
On Fri, Sep 20, 2013 at 11:19 AM, Angel Ezquerra
<angel.ezquerra@gmail.com>wrote:

> On Fri, Sep 20, 2013 at 4:52 PM, Augie Fackler <raf@durin42.com> wrote:
> > On Sun, Sep 08, 2013 at 02:07:02AM +0200, Angel Ezquerra wrote:
> >> On Sun, Sep 8, 2013 at 1:46 AM, Martin Geisler <martin@geisler.net>
> wrote:
> >> > Angel Ezquerra <angel.ezquerra@gmail.com> writes:
> >> >
> >> >> # HG changeset patch
> >> >> # User Angel Ezquerra <angel.ezquerra@gmail.com>
> >> >> # Date 1378420708 -7200
> >> >> #      Fri Sep 06 00:38:28 2013 +0200
> >> >> # Node ID 15548e5b1c00bd2f261e3c81d39f2465263bc3c3
> >> >> # Parent  1d07bf106c2ad1c7ef5e257e754ca8d858bd04b0
> >> >> merge: let the user choose to merge, keep local or keep remote
> subrepo revisions
> >> >>
> >> >> When a subrepo has changed on the local and remote revisions, prompt
> >> >> the user whether it wants to merge those subrepo revisions, keep the
> >> >> local revision or keep the remote revision.
> >> >>
> >> >> Up until now mercurial would always perform a merge on a subrepo that
> >> >> had changed on the local and the remote revisions. This is often
> >> >> inconvenient. For example:
> >> >>
> >> >> - You may want to perform the actual subrepo merge after you have
> >> >> merged the parent subrepo files.
> >> >>
> >> >> - Some subrepos may be considered "read only", in the sense that you
> >> >> are not supposed to add new revisions to them. In those cases
> "merging
> >> >> a subrepo" means choosing which _existing_ revision you want to use
> on
> >> >> the merged revision. This is often the case for subrepos that contain
> >> >> binary dependencies (such as DLLs, etc).
> >> >>
> >> >> This new prompt makes mercurial better cope with those common
> >> >> scenarios.
> >> >>
> >> >> Notes:
> >> >>
> >> >> - The default behavior (which is the one that is used when ui is not
> >> >> interactive) remains unchanged (i.e. merge is the default action).
> >> >> - This prompt will be shown even if the ui --tool flag is set.
> >> >> - I don't know of a way to test the "keep local" and "keep remote"
> >> >> options (i.e. to force the test to choose those options).
> >> >>
> >> >> diff -r 1d07bf106c2a -r 15548e5b1c00 mercurial/subrepo.py
> >> >> --- a/mercurial/subrepo.py    Wed Sep 04 18:42:55 2013 -0700
> >> >> +++ b/mercurial/subrepo.py    Fri Sep 06 00:38:28 2013 +0200
> >> >> @@ -201,9 +201,24 @@
> >> >>                  wctx.sub(s).get(r, overwrite)
> >> >>                  sm[s] = r
> >> >>              else:
> >> >> -                debug(s, "both sides changed, merge with", r)
> >> >> -                wctx.sub(s).merge(r)
> >> >> -                sm[s] = l
> >> >> +                debug(s, "both sides changed")
> >> >> +                option = repo.ui.promptchoice(
> >> >> +                    _(' subrepository %s diverged (local revision:
> %s, '
> >> >> +                      'remote revision: %s)\n'
> >> >> +                      '(M)erge, keep (l)ocal or keep (r)emote?'
> >> >> +                      '$$ &Merge $$ &Local $$ &Remote')
> >> >> +                    % (s, l[1][:12], r[1][:12]), 0)
> >> >
> >> > I can see in the tests that one can answer "m" to this prompt, but the
> >> > "(M)erge" suggests to me that I should answer "M". I quickly checked
> the
> >> > other prompts and I think all the other options are in lowercase.
> >>
> >> Martin,
> >>
> >> thanks for reviewing this patch.
> >>
> >> I hesitated when deciding the case for that option. The description
> >> example given on the ui.promptchoice method docstring seems to suggest
> >> that the default option should be capitalized:
> >>
> >> "would you like fries with that (Yn)? $$ &Yes $$ &No"
> >>
> >> That being said I also saw that most (if not all) other prompts do not
> >> follow that advice and usually are all lowercase, so I would not mind
> >> changing it for consistency's sake.
> >
> > If 'm' is the default, then it should be captialized (this is pretty
> > standard in CLI apps.) The prompt parser should accept both M and m,
> > as well as L and l etc.
>
> That is what I thought from looking at the example in the
> ui.promptchoice docstring. I will not send a new version of the patch
> then, unless you think there is something else that is worth
> improving?
>

I don't see anything worth improving, but I also don't have any opinions
about subrepos, so someone else will need to review this.
Angel Ezquerra - Sept. 20, 2013, 3:25 p.m.
El 20/09/2013 17:20, "Augie Fackler" <raf@durin42.com> escribió:
>
>
> On Fri, Sep 20, 2013 at 11:19 AM, Angel Ezquerra <angel.ezquerra@gmail.com>
wrote:
>>
>> On Fri, Sep 20, 2013 at 4:52 PM, Augie Fackler <raf@durin42.com> wrote:
>> > On Sun, Sep 08, 2013 at 02:07:02AM +0200, Angel Ezquerra wrote:
>> >> On Sun, Sep 8, 2013 at 1:46 AM, Martin Geisler <martin@geisler.net>
wrote:
>> >> > Angel Ezquerra <angel.ezquerra@gmail.com> writes:
>> >> >
>> >> >> # HG changeset patch
>> >> >> # User Angel Ezquerra <angel.ezquerra@gmail.com>
>> >> >> # Date 1378420708 -7200
>> >> >> #      Fri Sep 06 00:38:28 2013 +0200
>> >> >> # Node ID 15548e5b1c00bd2f261e3c81d39f2465263bc3c3
>> >> >> # Parent  1d07bf106c2ad1c7ef5e257e754ca8d858bd04b0
>> >> >> merge: let the user choose to merge, keep local or keep remote
subrepo revisions
>> >> >>
>> >> >> When a subrepo has changed on the local and remote revisions,
prompt
>> >> >> the user whether it wants to merge those subrepo revisions, keep
the
>> >> >> local revision or keep the remote revision.
>> >> >>
>> >> >> Up until now mercurial would always perform a merge on a subrepo
that
>> >> >> had changed on the local and the remote revisions. This is often
>> >> >> inconvenient. For example:
>> >> >>
>> >> >> - You may want to perform the actual subrepo merge after you have
>> >> >> merged the parent subrepo files.
>> >> >>
>> >> >> - Some subrepos may be considered "read only", in the sense that
you
>> >> >> are not supposed to add new revisions to them. In those cases
"merging
>> >> >> a subrepo" means choosing which _existing_ revision you want to
use on
>> >> >> the merged revision. This is often the case for subrepos that
contain
>> >> >> binary dependencies (such as DLLs, etc).
>> >> >>
>> >> >> This new prompt makes mercurial better cope with those common
>> >> >> scenarios.
>> >> >>
>> >> >> Notes:
>> >> >>
>> >> >> - The default behavior (which is the one that is used when ui is
not
>> >> >> interactive) remains unchanged (i.e. merge is the default action).
>> >> >> - This prompt will be shown even if the ui --tool flag is set.
>> >> >> - I don't know of a way to test the "keep local" and "keep remote"
>> >> >> options (i.e. to force the test to choose those options).
>> >> >>
>> >> >> diff -r 1d07bf106c2a -r 15548e5b1c00 mercurial/subrepo.py
>> >> >> --- a/mercurial/subrepo.py    Wed Sep 04 18:42:55 2013 -0700
>> >> >> +++ b/mercurial/subrepo.py    Fri Sep 06 00:38:28 2013 +0200
>> >> >> @@ -201,9 +201,24 @@
>> >> >>                  wctx.sub(s).get(r, overwrite)
>> >> >>                  sm[s] = r
>> >> >>              else:
>> >> >> -                debug(s, "both sides changed, merge with", r)
>> >> >> -                wctx.sub(s).merge(r)
>> >> >> -                sm[s] = l
>> >> >> +                debug(s, "both sides changed")
>> >> >> +                option = repo.ui.promptchoice(
>> >> >> +                    _(' subrepository %s diverged (local
revision: %s, '
>> >> >> +                      'remote revision: %s)\n'
>> >> >> +                      '(M)erge, keep (l)ocal or keep (r)emote?'
>> >> >> +                      '$$ &Merge $$ &Local $$ &Remote')
>> >> >> +                    % (s, l[1][:12], r[1][:12]), 0)
>> >> >
>> >> > I can see in the tests that one can answer "m" to this prompt, but
the
>> >> > "(M)erge" suggests to me that I should answer "M". I quickly
checked the
>> >> > other prompts and I think all the other options are in lowercase.
>> >>
>> >> Martin,
>> >>
>> >> thanks for reviewing this patch.
>> >>
>> >> I hesitated when deciding the case for that option. The description
>> >> example given on the ui.promptchoice method docstring seems to suggest
>> >> that the default option should be capitalized:
>> >>
>> >> "would you like fries with that (Yn)? $$ &Yes $$ &No"
>> >>
>> >> That being said I also saw that most (if not all) other prompts do not
>> >> follow that advice and usually are all lowercase, so I would not mind
>> >> changing it for consistency's sake.
>> >
>> > If 'm' is the default, then it should be captialized (this is pretty
>> > standard in CLI apps.) The prompt parser should accept both M and m,
>> > as well as L and l etc.
>>
>> That is what I thought from looking at the example in the
>> ui.promptchoice docstring. I will not send a new version of the patch
>> then, unless you think there is something else that is worth
>> improving?
>
>
> I don't see anything worth improving, but I also don't have any opinions
about subrepos, so someone else will need to review this.

Ok, thanks!

Angel

Patch

diff -r 1d07bf106c2a -r 15548e5b1c00 mercurial/subrepo.py
--- a/mercurial/subrepo.py	Wed Sep 04 18:42:55 2013 -0700
+++ b/mercurial/subrepo.py	Fri Sep 06 00:38:28 2013 +0200
@@ -201,9 +201,24 @@ 
                 wctx.sub(s).get(r, overwrite)
                 sm[s] = r
             else:
-                debug(s, "both sides changed, merge with", r)
-                wctx.sub(s).merge(r)
-                sm[s] = l
+                debug(s, "both sides changed")
+                option = repo.ui.promptchoice(
+                    _(' subrepository %s diverged (local revision: %s, '
+                      'remote revision: %s)\n'
+                      '(M)erge, keep (l)ocal or keep (r)emote?'
+                      '$$ &Merge $$ &Local $$ &Remote')
+                    % (s, l[1][:12], r[1][:12]), 0)
+                if option == 0:
+                    wctx.sub(s).merge(r)
+                    sm[s] = l
+                    debug(s, "merge with", r)
+                elif option == 1:
+                    sm[s] = l
+                    debug(s, "keep local subrepo revision", l)
+                else:
+                    wctx.sub(s).get(r, overwrite)
+                    sm[s] = r
+                    debug(s, "get remote subrepo revision", r)
         elif ld == a: # remote removed, local unchanged
             debug(s, "remote removed, remove")
             wctx.sub(s).remove()
diff -r 1d07bf106c2a -r 15548e5b1c00 tests/test-mq-subrepo.t
--- a/tests/test-mq-subrepo.t	Wed Sep 04 18:42:55 2013 -0700
+++ b/tests/test-mq-subrepo.t	Fri Sep 06 00:38:28 2013 +0200
@@ -263,6 +263,8 @@ 
   adding sub/a
   $ hg qpush
   applying 1.diff
+   subrepository sub diverged (local revision: b2fdb12cd82b, remote revision: aa037b301eba)
+  (M)erge, keep (l)ocal or keep (r)emote? m
   1 files updated, 0 files merged, 0 files removed, 0 files unresolved
   now at: 1.diff
   $ hg status -AS
diff -r 1d07bf106c2a -r 15548e5b1c00 tests/test-subrepo.t
--- a/tests/test-subrepo.t	Wed Sep 04 18:42:55 2013 -0700
+++ b/tests/test-subrepo.t	Fri Sep 06 00:38:28 2013 +0200
@@ -236,7 +236,9 @@ 
    .hgsubstate: versions differ -> m
   updating: .hgsubstate 1/1 files (100.00%)
   subrepo merge e45c8b14af55+ f94576341bcf 1831e14459c4
-    subrepo t: both sides changed, merge with t:7af322bc1198a32402fe903e0b7ebcfc5c9bf8f4:hg
+    subrepo t: both sides changed 
+   subrepository t diverged (local revision: 20a0db6fbf6c, remote revision: 7af322bc1198)
+  (M)erge, keep (l)ocal or keep (r)emote? m
   merging subrepo t
     searching for copies back to rev 2
   resolving manifests
@@ -252,6 +254,7 @@ 
   merging t incomplete! (edit conflicts, then use 'hg resolve --mark')
   0 files updated, 0 files merged, 0 files removed, 1 files unresolved
   use 'hg resolve' to retry unresolved file merges or 'hg update -C .' to abandon
+    subrepo t: merge with t:7af322bc1198a32402fe903e0b7ebcfc5c9bf8f4:hg
   0 files updated, 0 files merged, 0 files removed, 0 files unresolved
   (branch merge, don't forget to commit)
 
@@ -620,6 +623,8 @@ 
   $ hg up 5
   0 files updated, 0 files merged, 0 files removed, 0 files unresolved
   $ hg merge 4    # try to merge default into br again
+   subrepository s diverged (local revision: f8f13b33206e, remote revision: a3f9062a4f88)
+  (M)erge, keep (l)ocal or keep (r)emote? m
   1 files updated, 0 files merged, 0 files removed, 0 files unresolved
   (branch merge, don't forget to commit)
   $ cd ..
@@ -922,9 +927,13 @@ 
   $ hg -R t id
   e95bcfa18a35+
   $ hg update tip
+   subrepository s diverged (local revision: fc627a69481f, remote revision: 12a213df6fa9)
+  (M)erge, keep (l)ocal or keep (r)emote? m
    subrepository sources for s differ
   use (l)ocal source (fc627a69481f) or (r)emote source (12a213df6fa9)?
    l
+   subrepository t diverged (local revision: e95bcfa18a35, remote revision: 52c0adc0515a)
+  (M)erge, keep (l)ocal or keep (r)emote? m
    subrepository sources for t differ
   use (l)ocal source (e95bcfa18a35) or (r)emote source (52c0adc0515a)?
    l
@@ -953,6 +962,10 @@ 
   1 files updated, 0 files merged, 0 files removed, 0 files unresolved
   $ cd ..
   $ hg update 10
+   subrepository s diverged (local revision: 12a213df6fa9, remote revision: fc627a69481f)
+  (M)erge, keep (l)ocal or keep (r)emote? m
+   subrepository t diverged (local revision: 52c0adc0515a, remote revision: 20a0db6fbf6c)
+  (M)erge, keep (l)ocal or keep (r)emote? m
    subrepository sources for t differ (in checked out version)
   use (l)ocal source (7af322bc1198) or (r)emote source (20a0db6fbf6c)?
    l
@@ -976,9 +989,13 @@ 
   $ hg -R t id
   7af322bc1198+
   $ hg update tip
+   subrepository s diverged (local revision: 12a213df6fa9, remote revision: 12a213df6fa9)
+  (M)erge, keep (l)ocal or keep (r)emote? m
    subrepository sources for s differ
   use (l)ocal source (02dcf1d70411) or (r)emote source (12a213df6fa9)?
    l
+   subrepository t diverged (local revision: 52c0adc0515a, remote revision: 52c0adc0515a)
+  (M)erge, keep (l)ocal or keep (r)emote? m
    subrepository sources for t differ
   use (l)ocal source (7af322bc1198) or (r)emote source (52c0adc0515a)?
    l
@@ -1006,6 +1023,8 @@ 
   1 files updated, 0 files merged, 0 files removed, 0 files unresolved
   $ cd ..
   $ hg update 11
+   subrepository s diverged (local revision: 12a213df6fa9, remote revision: fc627a69481f)
+  (M)erge, keep (l)ocal or keep (r)emote? m
   0 files updated, 0 files merged, 0 files removed, 0 files unresolved
   0 files updated, 0 files merged, 0 files removed, 0 files unresolved
   $ hg id -n