inconsistency between pull -u and update

Matt Mackall mpm at selenic.com
Tue May 31 00:30:21 CDT 2011


On Mon, 2011-05-30 at 16:11 -0700, Brendan Cully wrote:
> On 2011-05-30, at 3:53 PM, Benoit Boissinot wrote:
> 
> > On Mon, May 30, 2011 at 12:29 AM, Brendan Cully <brendan at kublai.com> wrote:
> >> Why is it that 'hg update' will pick the tipmost head of the current
> >> named branch, but 'hg pull -u' will bail out if there is more than one
> >> head? For clarity, I have a shell demonstration below.
> >> 
> >> The pull -u behaviour makes more sense to me. If the behavior should
> >> be the same, maybe we should push the logic for picking the right
> >> revision into hg.update or merge.update?
> > 
> > This was changed (unintentionally) in
> > http://hg.kublai.com/mercurial/main/rev/ced2d3620f95
> > Probably too late to change it now?
> > 
> > In fact I don't think it works like you describe it, we don't abort
> > because there are several heads, but because the pull added new heads.
> 
> You're right. If I pull -u, I can get a failure that heads or added.
> If I then add another change to either head in the source, pull -u
> will succeed the second time.
> 
> This seems pretty weird to me. But it's set in stone for backward
> compatibility?

update's behavior: yes, it's been documented that way back to 1.0:

    Update the working directory to the specified revision, or the
    tip of the current branch if none is specified.

pull -u's behavior: no, it's been documented thusly:

1.0:  -u --update     update to new tip if changesets were pulled
1.5:  -u --update     update to new branch head if changesets were
pulled

And I've always described it as 'pull && update'. So it looks like the
current pull -u behavior should be considered buggy, especially in light
of your second pull above.

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list