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

Sune Foldager cryo at cyanite.org
Tue Apr 27 16:10:35 CDT 2010


On 23-04-2010 01:09, Matt Mackall wrote:
> Ok, here's a proposed lookupbranch algorithm:
> 
> def lookupbranch(repo, id, fallback=None):
>   if id is known branch in primary repo (ie remote for pull):
>     use it

+1

>   if id is known branch in fallback repo (ie local for pull):
>     use it # may be a no-op

This is always bound to fail, so we don't need this step. If the branch
doesn't exist remotely, its existance locally won't do us any good for a
pull.


>   if id is '.':
>     use branch from local working directory

+1, but I'll check this before anything else.

>   if id is known non-branch in primary repo:
>     try to use repo[id].branch()
>     except: # can't look up branch over the wire

...and over the wire is all we need the fallback for, so this code will
always fail.

>       if repo.lookup(id) == fallback.lookup(id): # but have it locally
>         use fallback[id].branch()

+1 if this means: if we have the id remotely and locally, use local branch.

>       else: # no way to get a branch
>         raise "sorry, can't use -b rev with that repo"

+1

>   if id is known in fallback repo:
>     use fallback[id].branch()

-1, this is the case I don't like. If the cset doesn't exist remotely,
and we're doing a pull, but we have a matching changeset locally (which
may be completely unrelated), I don't think we should use it. Better to
fail.

> When does this do something confusing?

In the -1 case above :). Otherwise I agree.

On an implementation node, I'll code this in addbranchrevs first, since
it can run efficiently there and requires no API changes. We can always
move that to lookupbranch later. In the mean time, I really think we
should remove the fallback code in lookupbranch, since it's buggy and
won't do anything useful as it is.

/Sune :)


More information about the Mercurial-devel mailing list