inconsistency between pull -u and update
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
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
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