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

[Sean Farley]

Yuya Nishihara <yuya at 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 at 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.