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

[Matt Mackall]

On Tue, 2010-04-27 at 23:10 +0200, Sune Foldager wrote:
> 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.

Probably still worth doing for precedence reasons. If I have branch foo
locally and tag foo on branch bar remotely, I don't want -b foo to pull
branch bar when I know about a branch foo. Simply returning branch foo
here will do the right thing -> no incoming changes.

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

Eh?

hg pull -b 1.0 /some/local/repo <- repo = /some/repo, fallback = .

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

It does.

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

And I really can't figure out why you think that. The user has said
"give me everything from the branch associated with rev x" and you have
a pretty solid idea of what rev x is. Saying "we've never heard of x,
sorry" is not going to be very satisfactory when it's clearly sitting
right there ->.<-, you stupid computer.

Imagine for a moment that x is a bookmark. I've made a commit on my
bookmark foo-proj and then want to pull everything on that branch. Maybe
I work with you or GregW, so I have a ridiculous number of heads and
branches that I can't be bothered to keep track of, and I use bookmarks
for the three I care about. hg pull -b foo-proj means "pull the branch
associated with that bookmark so I can get my merge on" and the fact
that bookmarks are currently local-only means that will never work in
your world.

Perhaps you're getting bogged down in the symmetry problem. Indeed pull
-r local-only-branch-or-rev has no sensible interpretation that will
ever result in moving csets around, and thus we've historically ignored
what's in localrepo. However, the error message is bogus:

$ hg pull -r foo b
pulling from b
abort: unknown revision 'foo'!

Here we know what foo is (in this case, a local branch), as it exists
locally. We should instead say "foo only exists locally, sorry" if we
can ever be bothered to improve it. But in the -b case, a local rev can
refer to interesting remote csets because the branch:rev relation is
1:n.

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

Sure.

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