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

[FUJIWARA Katsunori]

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 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?

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 at lares.dti.ne.jp