Patchwork [1,of,4] pull: work as usual bare "hg update" for URL#BRANCH

login
register
mail settings
Submitter Katsunori FUJIWARA
Date Feb. 17, 2016, 7:49 p.m.
Message ID <4da9702b2eef28a1c609.1455738565@feefifofum>
Download mbox | patch
Permalink /patch/13245/
State Deferred
Headers show

Comments

Katsunori FUJIWARA - Feb. 17, 2016, 7:49 p.m.
# HG changeset patch
# User FUJIWARA Katsunori <foozy@lares.dti.ne.jp>
# Date 1455738388 -32400
#      Thu Feb 18 04:46:28 2016 +0900
# Node ID 4da9702b2eef28a1c6097f5dbce322bec8925fcd
# Parent  95bf01b8754016200a99fd3538e78030b2028c60
pull: work as usual bare "hg update" for URL#BRANCH

Ordinarily, "hg pull -u" works as same as "hg pull" + bare "hg update"
(without any explicit revision), for example:

  - advance current active bookmark, if the destination of the update
    is valid for 'bookmarks.validdest()'

  - update not to branch tip but to active bookmark, if the latter is
    already updated at pulling changes

But before this patch, "hg pull -u" for "URL#BRANCH" doesn't work as
expected.

  - current active bookmark is never advanced

  - update to branch tip always

This seems not reasonable for a user, who works on the branch "BRANCH"
in the repo cloned by "URL#BRANCH".

But, on the other hand, if "hg pull" is executed with explicit
--branch/--rev, or "URL#ANOTHER-BRANCH" source, this behavior seems
reasonable, because user would want to update to specified revision
(or branch tip).

This patch treats updating at "hg pull -u" as bare "hg update", if:

  - no --branch/--rev is specified, and
  - current branch name is equal to "fragment" of "URL#fragment"

In this case, 'checkout = None' makes postincoming() use
destutil.destupdate() to calculate the destination of the update and
the bookmark to be advanced, as same as usual bare "hg update".

This patch doesn't examine whether explicit --bookmark is specified or
not, because it isn't used to determine which revision should be
'checkout'.
Yuya Nishihara - Feb. 20, 2016, 7:05 a.m.
On Thu, 18 Feb 2016 04:49:25 +0900, FUJIWARA Katsunori wrote:
> # HG changeset patch
> # User FUJIWARA Katsunori <foozy@lares.dti.ne.jp>
> # Date 1455738388 -32400
> #      Thu Feb 18 04:46:28 2016 +0900
> # Node ID 4da9702b2eef28a1c6097f5dbce322bec8925fcd
> # Parent  95bf01b8754016200a99fd3538e78030b2028c60
> pull: work as usual bare "hg update" for URL#BRANCH
> 
> Ordinarily, "hg pull -u" works as same as "hg pull" + bare "hg update"
> (without any explicit revision), for example:
> 
>   - advance current active bookmark, if the destination of the update
>     is valid for 'bookmarks.validdest()'
> 
>   - update not to branch tip but to active bookmark, if the latter is
>     already updated at pulling changes
> 
> But before this patch, "hg pull -u" for "URL#BRANCH" doesn't work as
> expected.
> 
>   - current active bookmark is never advanced
> 
>   - update to branch tip always
> 
> This seems not reasonable for a user, who works on the branch "BRANCH"
> in the repo cloned by "URL#BRANCH".
> 
> But, on the other hand, if "hg pull" is executed with explicit
> --branch/--rev, or "URL#ANOTHER-BRANCH" source, this behavior seems
> reasonable, because user would want to update to specified revision
> (or branch tip).
> 
> This patch treats updating at "hg pull -u" as bare "hg update", if:
> 
>   - no --branch/--rev is specified, and
>   - current branch name is equal to "fragment" of "URL#fragment"
> 
> In this case, 'checkout = None' makes postincoming() use
> destutil.destupdate() to calculate the destination of the update and
> the bookmark to be advanced, as same as usual bare "hg update".

New behavior makes more sense to me, but I don't think "pull -u -bBRANCH URL"
should be different from "pull -u URL#BRANCH". Also, it is surprising that
"pull -u URL#BRANCH" does update to BRANCH tip if wdir is not at BRANCH.

  $ hg clone URL#A foo
  $ cd foo
  $ hg pull -u  # takes me to max(.::(head() and branch(A)))
  $ hg branch B
  $ hg ci
  ... doing lots of works ...
  $ hg pull -u  # why switching to the branch A?

If we go this direction, I think "pull -u" should always select the default
update destination, er, unless -rREV is specified?
Katsunori FUJIWARA - Feb. 20, 2016, 6:31 p.m.
At Sat, 20 Feb 2016 16:05:32 +0900,
Yuya Nishihara wrote:
> 
> On Thu, 18 Feb 2016 04:49:25 +0900, FUJIWARA Katsunori wrote:
> > # HG changeset patch
> > # User FUJIWARA Katsunori <foozy@lares.dti.ne.jp>
> > # Date 1455738388 -32400
> > #      Thu Feb 18 04:46:28 2016 +0900
> > # Node ID 4da9702b2eef28a1c6097f5dbce322bec8925fcd
> > # Parent  95bf01b8754016200a99fd3538e78030b2028c60
> > pull: work as usual bare "hg update" for URL#BRANCH
> > 
> > Ordinarily, "hg pull -u" works as same as "hg pull" + bare "hg update"
> > (without any explicit revision), for example:
> > 
> >   - advance current active bookmark, if the destination of the update
> >     is valid for 'bookmarks.validdest()'
> > 
> >   - update not to branch tip but to active bookmark, if the latter is
> >     already updated at pulling changes
> > 
> > But before this patch, "hg pull -u" for "URL#BRANCH" doesn't work as
> > expected.
> > 
> >   - current active bookmark is never advanced
> > 
> >   - update to branch tip always
> > 
> > This seems not reasonable for a user, who works on the branch "BRANCH"
> > in the repo cloned by "URL#BRANCH".
> > 
> > But, on the other hand, if "hg pull" is executed with explicit
> > --branch/--rev, or "URL#ANOTHER-BRANCH" source, this behavior seems
> > reasonable, because user would want to update to specified revision
> > (or branch tip).
> > 
> > This patch treats updating at "hg pull -u" as bare "hg update", if:
> > 
> >   - no --branch/--rev is specified, and
> >   - current branch name is equal to "fragment" of "URL#fragment"
> > 
> > In this case, 'checkout = None' makes postincoming() use
> > destutil.destupdate() to calculate the destination of the update and
> > the bookmark to be advanced, as same as usual bare "hg update".
> 
> New behavior makes more sense to me, but I don't think "pull -u -bBRANCH URL"
> should be different from "pull -u URL#BRANCH". Also, it is surprising that
> "pull -u URL#BRANCH" does update to BRANCH tip if wdir is not at BRANCH.
> 
>   $ hg clone URL#A foo
>   $ cd foo
>   $ hg pull -u  # takes me to max(.::(head() and branch(A)))
>   $ hg branch B
>   $ hg ci
>   ... doing lots of works ...
>   $ hg pull -u  # why switching to the branch A?
> 
> If we go this direction, I think "pull -u" should always select the default
> update destination, er, unless -rREV is specified?

Would you mean that both of "-b BRANCH" or "URL#fragment" doesn't
affect to determining the destination of the update ?

----------------------------------------------------------------------
[FUJIWARA Katsunori]                             foozy@lares.dti.ne.jp
Yuya Nishihara - Feb. 21, 2016, 4:17 a.m.
On Sun, 21 Feb 2016 03:31:30 +0900, FUJIWARA Katsunori wrote:
> At Sat, 20 Feb 2016 16:05:32 +0900,
> Yuya Nishihara wrote:
> > On Thu, 18 Feb 2016 04:49:25 +0900, FUJIWARA Katsunori wrote:
> > > # HG changeset patch
> > > # User FUJIWARA Katsunori <foozy@lares.dti.ne.jp>
> > > # Date 1455738388 -32400
> > > #      Thu Feb 18 04:46:28 2016 +0900
> > > # Node ID 4da9702b2eef28a1c6097f5dbce322bec8925fcd
> > > # Parent  95bf01b8754016200a99fd3538e78030b2028c60
> > > pull: work as usual bare "hg update" for URL#BRANCH
> > > 
> > > Ordinarily, "hg pull -u" works as same as "hg pull" + bare "hg update"
> > > (without any explicit revision), for example:
> > > 
> > >   - advance current active bookmark, if the destination of the update
> > >     is valid for 'bookmarks.validdest()'
> > > 
> > >   - update not to branch tip but to active bookmark, if the latter is
> > >     already updated at pulling changes
> > > 
> > > But before this patch, "hg pull -u" for "URL#BRANCH" doesn't work as
> > > expected.
> > > 
> > >   - current active bookmark is never advanced
> > > 
> > >   - update to branch tip always
> > > 
> > > This seems not reasonable for a user, who works on the branch "BRANCH"
> > > in the repo cloned by "URL#BRANCH".
> > > 
> > > But, on the other hand, if "hg pull" is executed with explicit
> > > --branch/--rev, or "URL#ANOTHER-BRANCH" source, this behavior seems
> > > reasonable, because user would want to update to specified revision
> > > (or branch tip).
> > > 
> > > This patch treats updating at "hg pull -u" as bare "hg update", if:
> > > 
> > >   - no --branch/--rev is specified, and
> > >   - current branch name is equal to "fragment" of "URL#fragment"
> > > 
> > > In this case, 'checkout = None' makes postincoming() use
> > > destutil.destupdate() to calculate the destination of the update and
> > > the bookmark to be advanced, as same as usual bare "hg update".
> > 
> > New behavior makes more sense to me, but I don't think "pull -u -bBRANCH URL"
> > should be different from "pull -u URL#BRANCH". Also, it is surprising that
> > "pull -u URL#BRANCH" does update to BRANCH tip if wdir is not at BRANCH.
> > 
> >   $ hg clone URL#A foo
> >   $ cd foo
> >   $ hg pull -u  # takes me to max(.::(head() and branch(A)))
> >   $ hg branch B
> >   $ hg ci
> >   ... doing lots of works ...
> >   $ hg pull -u  # why switching to the branch A?
> > 
> > If we go this direction, I think "pull -u" should always select the default
> > update destination, er, unless -rREV is specified?
> 
> Would you mean that both of "-b BRANCH" or "URL#fragment" doesn't
> affect to determining the destination of the update ?

Or always affects no matter if wdir is BRANCH or not. It seems confusing for
me to switch "hg update" and "hg update BRANCH" by dirstate.branch().

 a) "hg pull -bB -u" == "hg pull -bB && hg update B"
 b) "hg pull -bB -u" == "hg pull -bB && hg update"

My opinion is (a) or (b) should be selected statically, not dynamically based
on current branch.

FWIW, this series would be tightly related to the update destination changes
which are ongoing. Do you know if "pull --update" was discussed in the last
Sprint?
Katsunori FUJIWARA - Feb. 21, 2016, 12:22 p.m.
(CC-ed to Pierre-Yves and Ryan for suggestion from point of view of
DefaultDestinationPlan)

At Sun, 21 Feb 2016 13:17:14 +0900,
Yuya Nishihara wrote:
> 
> On Sun, 21 Feb 2016 03:31:30 +0900, FUJIWARA Katsunori wrote:
> > At Sat, 20 Feb 2016 16:05:32 +0900,
> > Yuya Nishihara wrote:
> > > On Thu, 18 Feb 2016 04:49:25 +0900, FUJIWARA Katsunori wrote:
> > > > # HG changeset patch
> > > > # User FUJIWARA Katsunori <foozy@lares.dti.ne.jp>
> > > > # Date 1455738388 -32400
> > > > #      Thu Feb 18 04:46:28 2016 +0900
> > > > # Node ID 4da9702b2eef28a1c6097f5dbce322bec8925fcd
> > > > # Parent  95bf01b8754016200a99fd3538e78030b2028c60
> > > > pull: work as usual bare "hg update" for URL#BRANCH
> > > > 
> > > > Ordinarily, "hg pull -u" works as same as "hg pull" + bare "hg update"
> > > > (without any explicit revision), for example:
> > > > 
> > > >   - advance current active bookmark, if the destination of the update
> > > >     is valid for 'bookmarks.validdest()'
> > > > 
> > > >   - update not to branch tip but to active bookmark, if the latter is
> > > >     already updated at pulling changes
> > > > 
> > > > But before this patch, "hg pull -u" for "URL#BRANCH" doesn't work as
> > > > expected.
> > > > 
> > > >   - current active bookmark is never advanced
> > > > 
> > > >   - update to branch tip always
> > > > 
> > > > This seems not reasonable for a user, who works on the branch "BRANCH"
> > > > in the repo cloned by "URL#BRANCH".
> > > > 
> > > > But, on the other hand, if "hg pull" is executed with explicit
> > > > --branch/--rev, or "URL#ANOTHER-BRANCH" source, this behavior seems
> > > > reasonable, because user would want to update to specified revision
> > > > (or branch tip).
> > > > 
> > > > This patch treats updating at "hg pull -u" as bare "hg update", if:
> > > > 
> > > >   - no --branch/--rev is specified, and
> > > >   - current branch name is equal to "fragment" of "URL#fragment"
> > > > 
> > > > In this case, 'checkout = None' makes postincoming() use
> > > > destutil.destupdate() to calculate the destination of the update and
> > > > the bookmark to be advanced, as same as usual bare "hg update".
> > > 
> > > New behavior makes more sense to me, but I don't think "pull -u -bBRANCH URL"
> > > should be different from "pull -u URL#BRANCH". Also, it is surprising that
> > > "pull -u URL#BRANCH" does update to BRANCH tip if wdir is not at BRANCH.
> > > 
> > >   $ hg clone URL#A foo
> > >   $ cd foo
> > >   $ hg pull -u  # takes me to max(.::(head() and branch(A)))
> > >   $ hg branch B
> > >   $ hg ci
> > >   ... doing lots of works ...
> > >   $ hg pull -u  # why switching to the branch A?
> > > 
> > > If we go this direction, I think "pull -u" should always select the default
> > > update destination, er, unless -rREV is specified?
> > 
> > Would you mean that both of "-b BRANCH" or "URL#fragment" doesn't
> > affect to determining the destination of the update ?
> 
> Or always affects no matter if wdir is BRANCH or not. It seems confusing for
> me to switch "hg update" and "hg update BRANCH" by dirstate.branch().
> 
>  a) "hg pull -bB -u" == "hg pull -bB && hg update B"
>  b) "hg pull -bB -u" == "hg pull -bB && hg update"
> 
> My opinion is (a) or (b) should be selected statically, not dynamically based
> on current branch.

I think that current updating behavior of "pull -u" below is
reasonable in ordinary case, because user would want to update to
specified one immediately. So, I like (a) above.

  - update to specified revision (or the tipmost branch head),
    if -r REV, -b BRANCH, or URL#X is specified

  - otherwise, update like as bare "update"

A main concern of this patch is:

  even in the repo cloned via "URL#X", "pull -u" treats "#X" not as a
  part of "default" pulling source, but a kind of "-r X"

  => active bookmark isn't advanced as expected

  => branch might be switched unintentionally, as you described in
     previous reply above

Therefore, what about another solution below, even though this is a
kind of "dynamic" one, too ?

  - update like as bare "update", if "[paths] default" and pulling
    source have same fragment part

    (we might have to compare also between "#fragment" and "-b
    BRANCH", for similarity)

  - otherwise, update to specified fragment

Let's ignore the case, in which user changes "[paths] default"
configuration after cloning from "URL#X" :-)


> FWIW, this series would be tightly related to the update destination changes
> which are ongoing. Do you know if "pull --update" was discussed in the last
> Sprint?

No, all I know is the thing described in DefaultDestinationPlan wiki
page. It seems to make no mention of pulling from "URL#fragment".

  https://www.mercurial-scm.org/wiki/DefaultDestinationPlan


----------------------------------------------------------------------
[FUJIWARA Katsunori]                             foozy@lares.dti.ne.jp
Sune Foldager - Feb. 21, 2016, 1:13 p.m.
> On 21 Feb 2016, at 05:17, Yuya Nishihara <yuya@tcha.org <mailto:yuya@tcha.org>> wrote:
> 
> Or always affects no matter if wdir is BRANCH or not. It seems confusing for
> me to switch "hg update" and "hg update BRANCH" by dirstate.branch().
> 
> a) "hg pull -bB -u" == "hg pull -bB && hg update B"
> b) "hg pull -bB -u" == "hg pull -bB && hg update”

Did this change recently? Last time I checked hg pull -u doesn’t update if it doesn’t pull at least one changeset. In fact, our (company) Mercurial metatool, repoman, always updates when pulling, even with zero changesets pulled, but we did that because it confused people that it only did it sometimes.

In that case, neither a or b hold currently.

-Sune
Yuya Nishihara - Feb. 21, 2016, 3:31 p.m.
On Sun, 21 Feb 2016 14:13:45 +0100, Sune Foldager wrote:
> > On 21 Feb 2016, at 05:17, Yuya Nishihara <yuya@tcha.org> wrote:
> > Or always affects no matter if wdir is BRANCH or not. It seems confusing for
> > me to switch "hg update" and "hg update BRANCH" by dirstate.branch().
> > 
> > a) "hg pull -bB -u" == "hg pull -bB && hg update B"
> > b) "hg pull -bB -u" == "hg pull -bB && hg update”
> 
> Did this change recently? Last time I checked hg pull -u doesn’t update if
> it doesn’t pull at least one changeset.

Ah, no. I thought "hg pull" would return 1 if nothing pulled, but I'm wrong.
Yuya Nishihara - Feb. 21, 2016, 3:45 p.m.
On Sun, 21 Feb 2016 21:22:42 +0900, FUJIWARA Katsunori wrote:
> 
> (CC-ed to Pierre-Yves and Ryan for suggestion from point of view of
> DefaultDestinationPlan)
> 
> At Sun, 21 Feb 2016 13:17:14 +0900,
> Yuya Nishihara wrote:
> > 
> > On Sun, 21 Feb 2016 03:31:30 +0900, FUJIWARA Katsunori wrote:
> > > At Sat, 20 Feb 2016 16:05:32 +0900,
> > > Yuya Nishihara wrote:
> > > > On Thu, 18 Feb 2016 04:49:25 +0900, FUJIWARA Katsunori wrote:
> > > > > # HG changeset patch
> > > > > # User FUJIWARA Katsunori <foozy@lares.dti.ne.jp>
> > > > > # Date 1455738388 -32400
> > > > > #      Thu Feb 18 04:46:28 2016 +0900
> > > > > # Node ID 4da9702b2eef28a1c6097f5dbce322bec8925fcd
> > > > > # Parent  95bf01b8754016200a99fd3538e78030b2028c60
> > > > > pull: work as usual bare "hg update" for URL#BRANCH
> > > > > 
> > > > > Ordinarily, "hg pull -u" works as same as "hg pull" + bare "hg update"
> > > > > (without any explicit revision), for example:
> > > > > 
> > > > >   - advance current active bookmark, if the destination of the update
> > > > >     is valid for 'bookmarks.validdest()'
> > > > > 
> > > > >   - update not to branch tip but to active bookmark, if the latter is
> > > > >     already updated at pulling changes
> > > > > 
> > > > > But before this patch, "hg pull -u" for "URL#BRANCH" doesn't work as
> > > > > expected.
> > > > > 
> > > > >   - current active bookmark is never advanced
> > > > > 
> > > > >   - update to branch tip always
> > > > > 
> > > > > This seems not reasonable for a user, who works on the branch "BRANCH"
> > > > > in the repo cloned by "URL#BRANCH".
> > > > > 
> > > > > But, on the other hand, if "hg pull" is executed with explicit
> > > > > --branch/--rev, or "URL#ANOTHER-BRANCH" source, this behavior seems
> > > > > reasonable, because user would want to update to specified revision
> > > > > (or branch tip).
> > > > > 
> > > > > This patch treats updating at "hg pull -u" as bare "hg update", if:
> > > > > 
> > > > >   - no --branch/--rev is specified, and
> > > > >   - current branch name is equal to "fragment" of "URL#fragment"
> > > > > 
> > > > > In this case, 'checkout = None' makes postincoming() use
> > > > > destutil.destupdate() to calculate the destination of the update and
> > > > > the bookmark to be advanced, as same as usual bare "hg update".
> > > > 
> > > > New behavior makes more sense to me, but I don't think "pull -u -bBRANCH URL"
> > > > should be different from "pull -u URL#BRANCH". Also, it is surprising that
> > > > "pull -u URL#BRANCH" does update to BRANCH tip if wdir is not at BRANCH.
> > > > 
> > > >   $ hg clone URL#A foo
> > > >   $ cd foo
> > > >   $ hg pull -u  # takes me to max(.::(head() and branch(A)))
> > > >   $ hg branch B
> > > >   $ hg ci
> > > >   ... doing lots of works ...
> > > >   $ hg pull -u  # why switching to the branch A?
> > > > 
> > > > If we go this direction, I think "pull -u" should always select the default
> > > > update destination, er, unless -rREV is specified?
> > > 
> > > Would you mean that both of "-b BRANCH" or "URL#fragment" doesn't
> > > affect to determining the destination of the update ?
> > 
> > Or always affects no matter if wdir is BRANCH or not. It seems confusing for
> > me to switch "hg update" and "hg update BRANCH" by dirstate.branch().
> > 
> >  a) "hg pull -bB -u" == "hg pull -bB && hg update B"
> >  b) "hg pull -bB -u" == "hg pull -bB && hg update"
> > 
> > My opinion is (a) or (b) should be selected statically, not dynamically based
> > on current branch.
> 
> I think that current updating behavior of "pull -u" below is
> reasonable in ordinary case, because user would want to update to
> specified one immediately. So, I like (a) above.
> 
>   - update to specified revision (or the tipmost branch head),
>     if -r REV, -b BRANCH, or URL#X is specified
> 
>   - otherwise, update like as bare "update"
> 
> A main concern of this patch is:
> 
>   even in the repo cloned via "URL#X", "pull -u" treats "#X" not as a
>   part of "default" pulling source, but a kind of "-r X"
> 
>   => active bookmark isn't advanced as expected

Hmm, if "pull -u URL#X" is "pull && update X", I think that's okay.

FWIW, I heard we plan to change "hg update" not to move the active bookmark.
This patch series would hit the hot topic that I don't know well.

>   => branch might be switched unintentionally, as you described in
>      previous reply above
> 
> Therefore, what about another solution below, even though this is a
> kind of "dynamic" one, too ?
> 
>   - update like as bare "update", if "[paths] default" and pulling
>     source have same fragment part

Uh, do you mean only the default path#fragment is handled specially?
That would be confusing because the default path is just one of the stocked
paths.

>     (we might have to compare also between "#fragment" and "-b
>     BRANCH", for similarity)
> 
>   - otherwise, update to specified fragment
Sean Farley - Feb. 22, 2016, 7:22 p.m.
Yuya Nishihara <yuya@tcha.org> writes:

> On Sun, 21 Feb 2016 21:22:42 +0900, FUJIWARA Katsunori wrote:
>> 
>> (CC-ed to Pierre-Yves and Ryan for suggestion from point of view of
>> DefaultDestinationPlan)
>> 
>> At Sun, 21 Feb 2016 13:17:14 +0900,
>> Yuya Nishihara wrote:
>> > 
>> > On Sun, 21 Feb 2016 03:31:30 +0900, FUJIWARA Katsunori wrote:
>> > > At Sat, 20 Feb 2016 16:05:32 +0900,
>> > > Yuya Nishihara wrote:
>> > > > On Thu, 18 Feb 2016 04:49:25 +0900, FUJIWARA Katsunori wrote:
>> > > > > # HG changeset patch
>> > > > > # User FUJIWARA Katsunori <foozy@lares.dti.ne.jp>
>> > > > > # Date 1455738388 -32400
>> > > > > #      Thu Feb 18 04:46:28 2016 +0900
>> > > > > # Node ID 4da9702b2eef28a1c6097f5dbce322bec8925fcd
>> > > > > # Parent  95bf01b8754016200a99fd3538e78030b2028c60
>> > > > > pull: work as usual bare "hg update" for URL#BRANCH
>> > > > > 
>> > > > > Ordinarily, "hg pull -u" works as same as "hg pull" + bare "hg update"
>> > > > > (without any explicit revision), for example:
>> > > > > 
>> > > > >   - advance current active bookmark, if the destination of the update
>> > > > >     is valid for 'bookmarks.validdest()'
>> > > > > 
>> > > > >   - update not to branch tip but to active bookmark, if the latter is
>> > > > >     already updated at pulling changes
>> > > > > 
>> > > > > But before this patch, "hg pull -u" for "URL#BRANCH" doesn't work as
>> > > > > expected.
>> > > > > 
>> > > > >   - current active bookmark is never advanced
>> > > > > 
>> > > > >   - update to branch tip always
>> > > > > 
>> > > > > This seems not reasonable for a user, who works on the branch "BRANCH"
>> > > > > in the repo cloned by "URL#BRANCH".
>> > > > > 
>> > > > > But, on the other hand, if "hg pull" is executed with explicit
>> > > > > --branch/--rev, or "URL#ANOTHER-BRANCH" source, this behavior seems
>> > > > > reasonable, because user would want to update to specified revision
>> > > > > (or branch tip).
>> > > > > 
>> > > > > This patch treats updating at "hg pull -u" as bare "hg update", if:
>> > > > > 
>> > > > >   - no --branch/--rev is specified, and
>> > > > >   - current branch name is equal to "fragment" of "URL#fragment"
>> > > > > 
>> > > > > In this case, 'checkout = None' makes postincoming() use
>> > > > > destutil.destupdate() to calculate the destination of the update and
>> > > > > the bookmark to be advanced, as same as usual bare "hg update".
>> > > > 
>> > > > New behavior makes more sense to me, but I don't think "pull -u -bBRANCH URL"
>> > > > should be different from "pull -u URL#BRANCH". Also, it is surprising that
>> > > > "pull -u URL#BRANCH" does update to BRANCH tip if wdir is not at BRANCH.
>> > > > 
>> > > >   $ hg clone URL#A foo
>> > > >   $ cd foo
>> > > >   $ hg pull -u  # takes me to max(.::(head() and branch(A)))
>> > > >   $ hg branch B
>> > > >   $ hg ci
>> > > >   ... doing lots of works ...
>> > > >   $ hg pull -u  # why switching to the branch A?
>> > > > 
>> > > > If we go this direction, I think "pull -u" should always select the default
>> > > > update destination, er, unless -rREV is specified?
>> > > 
>> > > Would you mean that both of "-b BRANCH" or "URL#fragment" doesn't
>> > > affect to determining the destination of the update ?
>> > 
>> > Or always affects no matter if wdir is BRANCH or not. It seems confusing for
>> > me to switch "hg update" and "hg update BRANCH" by dirstate.branch().
>> > 
>> >  a) "hg pull -bB -u" == "hg pull -bB && hg update B"
>> >  b) "hg pull -bB -u" == "hg pull -bB && hg update"
>> > 
>> > My opinion is (a) or (b) should be selected statically, not dynamically based
>> > on current branch.
>> 
>> I think that current updating behavior of "pull -u" below is
>> reasonable in ordinary case, because user would want to update to
>> specified one immediately. So, I like (a) above.
>> 
>>   - update to specified revision (or the tipmost branch head),
>>     if -r REV, -b BRANCH, or URL#X is specified
>> 
>>   - otherwise, update like as bare "update"
>> 
>> A main concern of this patch is:
>> 
>>   even in the repo cloned via "URL#X", "pull -u" treats "#X" not as a
>>   part of "default" pulling source, but a kind of "-r X"
>> 
>>   => active bookmark isn't advanced as expected
>
> Hmm, if "pull -u URL#X" is "pull && update X", I think that's okay.
>
> FWIW, I heard we plan to change "hg update" not to move the active bookmark.
> This patch series would hit the hot topic that I don't know well.

Yes, we discussed changing 'hg update' to not move the active bookmark
(BC). Instead, 'hg up -B .' would move it like it used to.
Katsunori FUJIWARA - Feb. 23, 2016, 8 p.m.
At Mon, 22 Feb 2016 11:22:54 -0800,
Sean Farley wrote:
> 
> 
> Yuya Nishihara <yuya@tcha.org> writes:
> 
> > On Sun, 21 Feb 2016 21:22:42 +0900, FUJIWARA Katsunori wrote:
> >> 
> >> (CC-ed to Pierre-Yves and Ryan for suggestion from point of view of
> >> DefaultDestinationPlan)
> >> 
> >> At Sun, 21 Feb 2016 13:17:14 +0900,
> >> Yuya Nishihara wrote:
> >> > 
> >> > On Sun, 21 Feb 2016 03:31:30 +0900, FUJIWARA Katsunori wrote:
> >> > > At Sat, 20 Feb 2016 16:05:32 +0900,
> >> > > Yuya Nishihara wrote:
> >> > > > On Thu, 18 Feb 2016 04:49:25 +0900, FUJIWARA Katsunori wrote:
> >> > > > > # HG changeset patch
> >> > > > > # User FUJIWARA Katsunori <foozy@lares.dti.ne.jp>
> >> > > > > # Date 1455738388 -32400
> >> > > > > #      Thu Feb 18 04:46:28 2016 +0900
> >> > > > > # Node ID 4da9702b2eef28a1c6097f5dbce322bec8925fcd
> >> > > > > # Parent  95bf01b8754016200a99fd3538e78030b2028c60
> >> > > > > pull: work as usual bare "hg update" for URL#BRANCH
> >> > > > > 
> >> > > > > Ordinarily, "hg pull -u" works as same as "hg pull" + bare "hg update"
> >> > > > > (without any explicit revision), for example:
> >> > > > > 
> >> > > > >   - advance current active bookmark, if the destination of the update
> >> > > > >     is valid for 'bookmarks.validdest()'
> >> > > > > 
> >> > > > >   - update not to branch tip but to active bookmark, if the latter is
> >> > > > >     already updated at pulling changes
> >> > > > > 
> >> > > > > But before this patch, "hg pull -u" for "URL#BRANCH" doesn't work as
> >> > > > > expected.
> >> > > > > 
> >> > > > >   - current active bookmark is never advanced
> >> > > > > 
> >> > > > >   - update to branch tip always
> >> > > > > 
> >> > > > > This seems not reasonable for a user, who works on the branch "BRANCH"
> >> > > > > in the repo cloned by "URL#BRANCH".
> >> > > > > 
> >> > > > > But, on the other hand, if "hg pull" is executed with explicit
> >> > > > > --branch/--rev, or "URL#ANOTHER-BRANCH" source, this behavior seems
> >> > > > > reasonable, because user would want to update to specified revision
> >> > > > > (or branch tip).
> >> > > > > 
> >> > > > > This patch treats updating at "hg pull -u" as bare "hg update", if:
> >> > > > > 
> >> > > > >   - no --branch/--rev is specified, and
> >> > > > >   - current branch name is equal to "fragment" of "URL#fragment"
> >> > > > > 
> >> > > > > In this case, 'checkout = None' makes postincoming() use
> >> > > > > destutil.destupdate() to calculate the destination of the update and
> >> > > > > the bookmark to be advanced, as same as usual bare "hg update".
> >> > > > 
> >> > > > New behavior makes more sense to me, but I don't think "pull -u -bBRANCH URL"
> >> > > > should be different from "pull -u URL#BRANCH". Also, it is surprising that
> >> > > > "pull -u URL#BRANCH" does update to BRANCH tip if wdir is not at BRANCH.
> >> > > > 
> >> > > >   $ hg clone URL#A foo
> >> > > >   $ cd foo
> >> > > >   $ hg pull -u  # takes me to max(.::(head() and branch(A)))
> >> > > >   $ hg branch B
> >> > > >   $ hg ci
> >> > > >   ... doing lots of works ...
> >> > > >   $ hg pull -u  # why switching to the branch A?
> >> > > > 
> >> > > > If we go this direction, I think "pull -u" should always select the default
> >> > > > update destination, er, unless -rREV is specified?
> >> > > 
> >> > > Would you mean that both of "-b BRANCH" or "URL#fragment" doesn't
> >> > > affect to determining the destination of the update ?
> >> > 
> >> > Or always affects no matter if wdir is BRANCH or not. It seems confusing for
> >> > me to switch "hg update" and "hg update BRANCH" by dirstate.branch().
> >> > 
> >> >  a) "hg pull -bB -u" == "hg pull -bB && hg update B"
> >> >  b) "hg pull -bB -u" == "hg pull -bB && hg update"
> >> > 
> >> > My opinion is (a) or (b) should be selected statically, not dynamically based
> >> > on current branch.
> >> 
> >> I think that current updating behavior of "pull -u" below is
> >> reasonable in ordinary case, because user would want to update to
> >> specified one immediately. So, I like (a) above.
> >> 
> >>   - update to specified revision (or the tipmost branch head),
> >>     if -r REV, -b BRANCH, or URL#X is specified
> >> 
> >>   - otherwise, update like as bare "update"
> >> 
> >> A main concern of this patch is:
> >> 
> >>   even in the repo cloned via "URL#X", "pull -u" treats "#X" not as a
> >>   part of "default" pulling source, but a kind of "-r X"
> >> 
> >>   => active bookmark isn't advanced as expected
> >
> > Hmm, if "pull -u URL#X" is "pull && update X", I think that's okay.
> >
> > FWIW, I heard we plan to change "hg update" not to move the active bookmark.
> > This patch series would hit the hot topic that I don't know well.
> 
> Yes, we discussed changing 'hg update' to not move the active bookmark
> (BC). Instead, 'hg up -B .' would move it like it used to.

I see. "changing 'hg update' to not move the active bookmark" makes
this patch (#1) meaningless.

BTW, rest of this series is a preparation for the next series, which
centralizes similar combination logic of below procedures in
commands.postincoming() and commands.update(), in fact.

  - destutil.destupdate()
  - hg.udate()/clean() and
  - advancing/(in)activating bookmark

I'm planning to make rebase and fetch reuse centralized one in "bare
update" case, too.

But should I hold these patches for a while, to avoid conflict against
your "changing 'hg update' to not move the active bookmark" works ?
(or would you already have or plan such ones ?)

----------------------------------------------------------------------
[FUJIWARA Katsunori]                             foozy@lares.dti.ne.jp
Pierre-Yves David - Feb. 24, 2016, 4:33 p.m.
On 02/23/2016 09:00 PM, FUJIWARA Katsunori wrote:
> At Mon, 22 Feb 2016 11:22:54 -0800,
> Sean Farley wrote:
>>
>>
>> Yuya Nishihara <yuya@tcha.org> writes:
>>
>>> On Sun, 21 Feb 2016 21:22:42 +0900, FUJIWARA Katsunori wrote:
>>>>
>>>> (CC-ed to Pierre-Yves and Ryan for suggestion from point of view of
>>>> DefaultDestinationPlan)
>>>>
>>>> At Sun, 21 Feb 2016 13:17:14 +0900,
>>>> Yuya Nishihara wrote:
>>>>>
>>>>> On Sun, 21 Feb 2016 03:31:30 +0900, FUJIWARA Katsunori wrote:
>>>>>> At Sat, 20 Feb 2016 16:05:32 +0900,
>>>>>> Yuya Nishihara wrote:
>>>>>>> On Thu, 18 Feb 2016 04:49:25 +0900, FUJIWARA Katsunori wrote:
>>>>>>>> # HG changeset patch
>>>>>>>> # User FUJIWARA Katsunori <foozy@lares.dti.ne.jp>
>>>>>>>> # Date 1455738388 -32400
>>>>>>>> #      Thu Feb 18 04:46:28 2016 +0900
>>>>>>>> # Node ID 4da9702b2eef28a1c6097f5dbce322bec8925fcd
>>>>>>>> # Parent  95bf01b8754016200a99fd3538e78030b2028c60
>>>>>>>> pull: work as usual bare "hg update" for URL#BRANCH
>>>>>>>>
>>>>>>>> Ordinarily, "hg pull -u" works as same as "hg pull" + bare "hg update"
>>>>>>>> (without any explicit revision), for example:
>>>>>>>>
>>>>>>>>    - advance current active bookmark, if the destination of the update
>>>>>>>>      is valid for 'bookmarks.validdest()'
>>>>>>>>
>>>>>>>>    - update not to branch tip but to active bookmark, if the latter is
>>>>>>>>      already updated at pulling changes
>>>>>>>>
>>>>>>>> But before this patch, "hg pull -u" for "URL#BRANCH" doesn't work as
>>>>>>>> expected.
>>>>>>>>
>>>>>>>>    - current active bookmark is never advanced
>>>>>>>>
>>>>>>>>    - update to branch tip always
>>>>>>>>
>>>>>>>> This seems not reasonable for a user, who works on the branch "BRANCH"
>>>>>>>> in the repo cloned by "URL#BRANCH".
>>>>>>>>
>>>>>>>> But, on the other hand, if "hg pull" is executed with explicit
>>>>>>>> --branch/--rev, or "URL#ANOTHER-BRANCH" source, this behavior seems
>>>>>>>> reasonable, because user would want to update to specified revision
>>>>>>>> (or branch tip).
>>>>>>>>
>>>>>>>> This patch treats updating at "hg pull -u" as bare "hg update", if:
>>>>>>>>
>>>>>>>>    - no --branch/--rev is specified, and
>>>>>>>>    - current branch name is equal to "fragment" of "URL#fragment"
>>>>>>>>
>>>>>>>> In this case, 'checkout = None' makes postincoming() use
>>>>>>>> destutil.destupdate() to calculate the destination of the update and
>>>>>>>> the bookmark to be advanced, as same as usual bare "hg update".
>>>>>>>
>>>>>>> New behavior makes more sense to me, but I don't think "pull -u -bBRANCH URL"
>>>>>>> should be different from "pull -u URL#BRANCH". Also, it is surprising that
>>>>>>> "pull -u URL#BRANCH" does update to BRANCH tip if wdir is not at BRANCH.
>>>>>>>
>>>>>>>    $ hg clone URL#A foo
>>>>>>>    $ cd foo
>>>>>>>    $ hg pull -u  # takes me to max(.::(head() and branch(A)))
>>>>>>>    $ hg branch B
>>>>>>>    $ hg ci
>>>>>>>    ... doing lots of works ...
>>>>>>>    $ hg pull -u  # why switching to the branch A?
>>>>>>>
>>>>>>> If we go this direction, I think "pull -u" should always select the default
>>>>>>> update destination, er, unless -rREV is specified?
>>>>>>
>>>>>> Would you mean that both of "-b BRANCH" or "URL#fragment" doesn't
>>>>>> affect to determining the destination of the update ?
>>>>>
>>>>> Or always affects no matter if wdir is BRANCH or not. It seems confusing for
>>>>> me to switch "hg update" and "hg update BRANCH" by dirstate.branch().
>>>>>
>>>>>   a) "hg pull -bB -u" == "hg pull -bB && hg update B"
>>>>>   b) "hg pull -bB -u" == "hg pull -bB && hg update"
>>>>>
>>>>> My opinion is (a) or (b) should be selected statically, not dynamically based
>>>>> on current branch.
>>>>
>>>> I think that current updating behavior of "pull -u" below is
>>>> reasonable in ordinary case, because user would want to update to
>>>> specified one immediately. So, I like (a) above.
>>>>
>>>>    - update to specified revision (or the tipmost branch head),
>>>>      if -r REV, -b BRANCH, or URL#X is specified
>>>>
>>>>    - otherwise, update like as bare "update"
>>>>
>>>> A main concern of this patch is:
>>>>
>>>>    even in the repo cloned via "URL#X", "pull -u" treats "#X" not as a
>>>>    part of "default" pulling source, but a kind of "-r X"
>>>>
>>>>    => active bookmark isn't advanced as expected
>>>
>>> Hmm, if "pull -u URL#X" is "pull && update X", I think that's okay.
>>>
>>> FWIW, I heard we plan to change "hg update" not to move the active bookmark.
>>> This patch series would hit the hot topic that I don't know well.
>>
>> Yes, we discussed changing 'hg update' to not move the active bookmark
>> (BC). Instead, 'hg up -B .' would move it like it used to.
>
> I see. "changing 'hg update' to not move the active bookmark" makes
> this patch (#1) meaningless.
>
> BTW, rest of this series is a preparation for the next series, which
> centralizes similar combination logic of below procedures in
> commands.postincoming() and commands.update(), in fact.
>
>    - destutil.destupdate()
>    - hg.udate()/clean() and
>    - advancing/(in)activating bookmark
>
> I'm planning to make rebase and fetch reuse centralized one in "bare
> update" case, too.

So… what is the status of this series? Should we wait for a V2 ? pick 
some of it?

Do you have a clearer view of what are the behavior question and anwser? 
Are you going to clarify them in your V2 ? Or is there still unanswered 
question blocking your work?

> But should I hold these patches for a while, to avoid conflict against
> your "changing 'hg update' to not move the active bookmark" works ?
> (or would you already have or plan such ones ?)

I'm not aware of people actively working on this grand plan completion 
at the moment (even if some stone could be in flight about it)

Cheers,
Katsunori FUJIWARA - Feb. 25, 2016, 9:23 p.m.
At Wed, 24 Feb 2016 17:33:27 +0100,
Pierre-Yves David wrote:
> 
> 
> 
> On 02/23/2016 09:00 PM, FUJIWARA Katsunori wrote:
> > At Mon, 22 Feb 2016 11:22:54 -0800,
> > Sean Farley wrote:
> >>
> >>
> >> Yuya Nishihara <yuya@tcha.org> writes:
> >>
> >>> On Sun, 21 Feb 2016 21:22:42 +0900, FUJIWARA Katsunori wrote:
> >>>>
> >>>> (CC-ed to Pierre-Yves and Ryan for suggestion from point of view of
> >>>> DefaultDestinationPlan)
> >>>>
> >>>> At Sun, 21 Feb 2016 13:17:14 +0900,
> >>>> Yuya Nishihara wrote:
> >>>>>
> >>>>> On Sun, 21 Feb 2016 03:31:30 +0900, FUJIWARA Katsunori wrote:
> >>>>>> At Sat, 20 Feb 2016 16:05:32 +0900,
> >>>>>> Yuya Nishihara wrote:
> >>>>>>> On Thu, 18 Feb 2016 04:49:25 +0900, FUJIWARA Katsunori wrote:
> >>>>>>>> # HG changeset patch
> >>>>>>>> # User FUJIWARA Katsunori <foozy@lares.dti.ne.jp>
> >>>>>>>> # Date 1455738388 -32400
> >>>>>>>> #      Thu Feb 18 04:46:28 2016 +0900
> >>>>>>>> # Node ID 4da9702b2eef28a1c6097f5dbce322bec8925fcd
> >>>>>>>> # Parent  95bf01b8754016200a99fd3538e78030b2028c60
> >>>>>>>> pull: work as usual bare "hg update" for URL#BRANCH
> >>>>>>>>
> >>>>>>>> Ordinarily, "hg pull -u" works as same as "hg pull" + bare "hg update"
> >>>>>>>> (without any explicit revision), for example:
> >>>>>>>>
> >>>>>>>>    - advance current active bookmark, if the destination of the update
> >>>>>>>>      is valid for 'bookmarks.validdest()'
> >>>>>>>>
> >>>>>>>>    - update not to branch tip but to active bookmark, if the latter is
> >>>>>>>>      already updated at pulling changes
> >>>>>>>>
> >>>>>>>> But before this patch, "hg pull -u" for "URL#BRANCH" doesn't work as
> >>>>>>>> expected.
> >>>>>>>>
> >>>>>>>>    - current active bookmark is never advanced
> >>>>>>>>
> >>>>>>>>    - update to branch tip always
> >>>>>>>>
> >>>>>>>> This seems not reasonable for a user, who works on the branch "BRANCH"
> >>>>>>>> in the repo cloned by "URL#BRANCH".
> >>>>>>>>
> >>>>>>>> But, on the other hand, if "hg pull" is executed with explicit
> >>>>>>>> --branch/--rev, or "URL#ANOTHER-BRANCH" source, this behavior seems
> >>>>>>>> reasonable, because user would want to update to specified revision
> >>>>>>>> (or branch tip).
> >>>>>>>>
> >>>>>>>> This patch treats updating at "hg pull -u" as bare "hg update", if:
> >>>>>>>>
> >>>>>>>>    - no --branch/--rev is specified, and
> >>>>>>>>    - current branch name is equal to "fragment" of "URL#fragment"
> >>>>>>>>
> >>>>>>>> In this case, 'checkout = None' makes postincoming() use
> >>>>>>>> destutil.destupdate() to calculate the destination of the update and
> >>>>>>>> the bookmark to be advanced, as same as usual bare "hg update".
> >>>>>>>
> >>>>>>> New behavior makes more sense to me, but I don't think "pull -u -bBRANCH URL"
> >>>>>>> should be different from "pull -u URL#BRANCH". Also, it is surprising that
> >>>>>>> "pull -u URL#BRANCH" does update to BRANCH tip if wdir is not at BRANCH.
> >>>>>>>
> >>>>>>>    $ hg clone URL#A foo
> >>>>>>>    $ cd foo
> >>>>>>>    $ hg pull -u  # takes me to max(.::(head() and branch(A)))
> >>>>>>>    $ hg branch B
> >>>>>>>    $ hg ci
> >>>>>>>    ... doing lots of works ...
> >>>>>>>    $ hg pull -u  # why switching to the branch A?
> >>>>>>>
> >>>>>>> If we go this direction, I think "pull -u" should always select the default
> >>>>>>> update destination, er, unless -rREV is specified?
> >>>>>>
> >>>>>> Would you mean that both of "-b BRANCH" or "URL#fragment" doesn't
> >>>>>> affect to determining the destination of the update ?
> >>>>>
> >>>>> Or always affects no matter if wdir is BRANCH or not. It seems confusing for
> >>>>> me to switch "hg update" and "hg update BRANCH" by dirstate.branch().
> >>>>>
> >>>>>   a) "hg pull -bB -u" == "hg pull -bB && hg update B"
> >>>>>   b) "hg pull -bB -u" == "hg pull -bB && hg update"
> >>>>>
> >>>>> My opinion is (a) or (b) should be selected statically, not dynamically based
> >>>>> on current branch.
> >>>>
> >>>> I think that current updating behavior of "pull -u" below is
> >>>> reasonable in ordinary case, because user would want to update to
> >>>> specified one immediately. So, I like (a) above.
> >>>>
> >>>>    - update to specified revision (or the tipmost branch head),
> >>>>      if -r REV, -b BRANCH, or URL#X is specified
> >>>>
> >>>>    - otherwise, update like as bare "update"
> >>>>
> >>>> A main concern of this patch is:
> >>>>
> >>>>    even in the repo cloned via "URL#X", "pull -u" treats "#X" not as a
> >>>>    part of "default" pulling source, but a kind of "-r X"
> >>>>
> >>>>    => active bookmark isn't advanced as expected
> >>>
> >>> Hmm, if "pull -u URL#X" is "pull && update X", I think that's okay.
> >>>
> >>> FWIW, I heard we plan to change "hg update" not to move the active bookmark.
> >>> This patch series would hit the hot topic that I don't know well.
> >>
> >> Yes, we discussed changing 'hg update' to not move the active bookmark
> >> (BC). Instead, 'hg up -B .' would move it like it used to.
> >
> > I see. "changing 'hg update' to not move the active bookmark" makes
> > this patch (#1) meaningless.
> >
> > BTW, rest of this series is a preparation for the next series, which
> > centralizes similar combination logic of below procedures in
> > commands.postincoming() and commands.update(), in fact.
> >
> >    - destutil.destupdate()
> >    - hg.udate()/clean() and
> >    - advancing/(in)activating bookmark
> >
> > I'm planning to make rebase and fetch reuse centralized one in "bare
> > update" case, too.
> 
> So… what is the status of this series? Should we wait for a V2 ? pick 
> some of it?
> 
> Do you have a clearer view of what are the behavior question and anwser? 
> Are you going to clarify them in your V2 ? Or is there still unanswered 
> question blocking your work?

Now, nothing blocks my work. I'll send revised series (but not
including this #1), soon.

> > But should I hold these patches for a while, to avoid conflict against
> > your "changing 'hg update' to not move the active bookmark" works ?
> > (or would you already have or plan such ones ?)
> 
> I'm not aware of people actively working on this grand plan completion 
> at the moment (even if some stone could be in flight about it)

Then, I'll send the series for my centralization plan.

> Cheers,
> 
> -- 
> Pierre-Yves David
> 

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

Patch

diff --git a/mercurial/commands.py b/mercurial/commands.py
--- a/mercurial/commands.py
+++ b/mercurial/commands.py
@@ -5656,7 +5656,16 @@  def pull(ui, repo, source="default", **o
                                  bookmarks=opts.get('bookmark', ()),
                                  opargs=pullopargs).cgresult
         if checkout:
-            checkout = str(repo.changelog.rev(checkout))
+            fragment = branches[0]
+            # treat "hg pull -u URL#fragment" as same as "hg pull" +
+            # usual bare "hg update", if:
+            #   - no --branch/--rev, and
+            #   - branch name is equal to "fragment"
+            if (not opts.get('branch') and not opts.get('rev') and
+                repo.dirstate.branch() == fragment):
+                checkout = None
+            else:
+                checkout = str(repo.changelog.rev(checkout))
         repo._subtoppath = source
         try:
             ret = postincoming(ui, repo, modheads, opts.get('update'), checkout)
diff --git a/tests/test-pull-update.t b/tests/test-pull-update.t
--- a/tests/test-pull-update.t
+++ b/tests/test-pull-update.t
@@ -61,4 +61,134 @@  Should work:
   added 1 changesets with 1 changes to 1 files (-1 heads)
   1 files updated, 0 files merged, 0 files removed, 0 files unresolved
 
+Similarity between "hg update" and "hg pull -u" in handling bookmark
+====================================================================
+
+  $ hg branch -q bar
+  $ hg commit -m "bar #1"
+  $ hg --cwd .. clone -q t#bar clone-bar
+  $ echo bar2 >> foo
+  $ hg commit -m "bar #2"
+
+  $ cd ../clone-bar
+
+Test that "hg pull -u URL#fragment" is as same as "hg pull
+URL#fragment" + bare "hg update", if:
+- no explicit --branch/--rev and
+- current branch name is equal to "fragment" of "URL#fragment"
+
+(1) advancing active bookmark
+
+  $ hg branch
+  bar
+  $ hg parents -q
+  4:20a3d5b6ab59
+  $ hg bookmark active-before-pull
+  $ hg bookmarks
+   * active-before-pull        4:20a3d5b6ab59
+
+  $ hg pull -u
+  pulling from $TESTTMP/t (glob)
+  searching for changes
+  adding changesets
+  adding manifests
+  adding file changes
+  added 1 changesets with 1 changes to 1 files
+  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
+  updating bookmark active-before-pull
+
+  $ hg branch
+  bar
+  $ hg parents -q
+  5:9ed4148f9a91
+  $ hg bookmarks
+   * active-before-pull        5:9ed4148f9a91
+
+(discard pulled changes: strip is needed in this case, because
+rollback just rewinds bookmark, which is advanced at previous pulling)
+
+  $ hg update -q 20a3d5b6ab59
+  $ hg rollback -q
+  $ hg --config extensions.strip= strip -q 9ed4148f9a91
+
+(2) updating not to branch tip but to (already updated) active bookmark
+
+  $ echo bar3 >> ../t/foo
+  $ hg -R ../t commit -m "bar #3"
+  $ hg -R ../t bookmark -r 9ed4148f9a91 active-before-pull
+
+  $ hg bookmark -f active-before-pull
+  $ hg bookmarks
+   * active-before-pull        4:20a3d5b6ab59
+
+  $ hg pull -u
+  pulling from $TESTTMP/t (glob)
+  searching for changes
+  adding changesets
+  adding manifests
+  adding file changes
+  added 2 changesets with 2 changes to 1 files
+  updating bookmark active-before-pull
+  updating to active bookmark active-before-pull
+  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
+
+  $ hg parents -q
+  5:9ed4148f9a91
+  $ hg bookmarks
+   * active-before-pull        5:9ed4148f9a91
+
+Test updating for multiple heads:
+
+  $ hg -R ../t update -q 20a3d5b6ab59
+  $ echo bar4 >> ../t/foo
+  $ hg -R ../t commit -m "bar #4"
+  created new head
+
+  $ hg -R ../t log -G -b bar -T "{node|short}"
+  @  424b5eb9b087
+  |
+  | o  0c90a742bd4f
+  | |
+  | o  9ed4148f9a91
+  |/
+  o  20a3d5b6ab59
+  |
+
+(1) update linearly and show "other heads" status like as bare "hg
+update", if pulling even from "URL#BRANCH", but no explicit --branch/--rev
+
+  $ hg update -C -q 0c90a742bd4f
+
+  $ hg pull -u
+  pulling from $TESTTMP/t (glob)
+  searching for changes
+  adding changesets
+  adding manifests
+  adding file changes
+  added 1 changesets with 1 changes to 1 files (+1 heads)
+  0 files updated, 0 files merged, 0 files removed, 0 files unresolved
+  1 other heads for branch "bar"
+
+  $ hg parents -q
+  6:0c90a742bd4f
+
+(discard pulled changes)
+
+  $ hg update -C -q 0c90a742bd4f
+  $ hg rollback -q
+
+(2) update to "branch tip" on another topological branch, otherwise
+
+  $ hg pull -u -r bar
+  pulling from $TESTTMP/t (glob)
+  searching for changes
+  adding changesets
+  adding manifests
+  adding file changes
+  added 1 changesets with 1 changes to 1 files (+1 heads)
+  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
+
+  $ hg parents -q
+  7:424b5eb9b087
+
   $ cd ..