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

Pierre-Yves David pierre-yves.david at ens-lyon.org
Wed Feb 24 16:33:27 UTC 2016



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 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.
>
> 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,

-- 
Pierre-Yves David



More information about the Mercurial-devel mailing list