[PATCH] commands: add more robust support for 'hg log -b' (issue2078)

Matt Mackall mpm at selenic.com
Mon Apr 19 12:49:23 CDT 2010


On Mon, 2010-04-19 at 19:08 +0200, Sune Foldager wrote:
> On 19-04-2010 16:43, Matt Mackall wrote:
> > On Mon, 2010-04-19 at 11:51 +0200, Sune Foldager wrote:
> >>  Also, what about in/out/pull/push 
> >> (and clone)'s -b options? I use a semi-similar function there to perform 
> >> the lookups; there might be overlap, although "my" function does 
> >> something a bit more specific, as I recall (it's addbranchrevs, I think).
> > 
> > I think your function is returning a set of branch head revisions,
> > right? This one is returning a branch -name- only. So yours should wrap
> > this one and have a last ditch fallback where we return a single rev in
> > the case that key is a remote id that we can't get a branch name for
> > (yet).
> 
> Right. Well it's returning the complete branch head list, but yeah.
> 
> > The guiding principle should be that "in a context where a branch name
> > is wanted, a non-branch id is interpreted as the branch corresponding to
> > that id (where available)". This is the corollary to the existing
> > principle "in a context where a revision is wanted, a branch name refers
> > to the tipmost revision on that branch".
> 
> Right, and I agree, but in incoming/pull we can't do that due to
> limitations in the wire protocol (there is no way to look up a rev
> remotely and get its branch back).

This is your official notice that this point has been considered.

When the remote repo cannot do rev to branch lookup (ie where NOT
available), we will attempt to look up the rev locally, and, if we fail
that, lookupbranch will fail. See Steve's patch. in/pull should do the
_aforementioned_ fallback in addbranchrevs.

-- 
http://selenic.com : development and support for Mercurial and Linux




More information about the Mercurial-devel mailing list