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

Matt Mackall mpm at selenic.com
Thu Apr 22 16:27:59 CDT 2010

On Thu, 2010-04-22 at 21:49 +0200, Sune Foldager wrote:
> On 21-04-2010 02:08, Matt Mackall wrote:

> > Some tables should help clarify.
> Myeah... I'm not so sure. First, the table you made doesn't really tell
> us the order of the performed checks, even though this is important
> (especially when a name matches both a branch and a tag).

The point of this discussion is to add a very simple behavior:

"when using non-branch ids with a -b, try to find the relevant branch
and use that"

Clear your mind of any pre-conceived notions of how -b currently works
and how we got there and focus on that statement. It's a simple,
intuitive, useful, and directly analogous to the existing:

"when using non-rev ids with a -r, try to find the relevant revision and
use that"

That statement also answers just about all the questions you could have
about the behavior details. For instance, -b means branch so if I say -b
foo, and there's a branch foo, I'm obviously not talking about a tag,
I'm talking about a branch. If there's no branch named foo, then yes, it
could be a tag, bookmark, rev, etc. But we already have rules for that.

>  Second, -b and
> # behave 100% identically

And as I've explained and diagrammed, that's bogus and should change. -b
means --branch, not --branch, not --branch-or-maybe-rev. If you want to
use a rev, you just use -r.

>  and third, and related, the 1.5 behavior is
> not exactly as you describe. Let me try with a table, dealing only with
> pull (and incoming) -b or #. The first row is the check performed first,
> and so on.
> 1.5 behavior for pull -b foo or pull url#foo (for servers with branchmap
> capability):
> 'foo' matches          equivalent pull action
> --------------------------------------------------------------
> '.'                    -r <local dirstate branch>
> remote branch          -r head1 -r head2 ... for all heads
> anything else          -r foo

Ok, with the exception of '.' being local now, that's what was in my
table. If you disagree with that, then quote my table and point out
where you think I'm wrong, don't delete the table and replace it with
something using different jargon. Here's that 1.5 table again:

x      log -r x  log -b x   pull -r x  pull -b x  pull url#x
rev    x         empty[3]   a(x)       a(x)[1]    a(x)
rrev   n/a       n/a        a(x)       a(x)[1]    a(x)  
branch max(x)    x          a(max(x))  a(x)       a(x) 
tag    t(x)      empty[3]   a(t(x))    a(t(x))[1] a(t(x))
.      wp1       empty[3]   a(wp1)     a(wp1)[2]  a(wp1)[2]

That says:

 "when we pull -b rev, we pull all ancestors of the rev"
 "when we pull -b branch, we pull all ancestors of the entire branch"
 "when we pull -r branch, we pull all ancestors of the tipmost branch
 "when we pull -b tag, we look up the tag, then pull all the resulting

Note that no user actually cares that -b branch magically translates to
-r heads(branch) internally. That pull pulls a branch by sending a list
of heads is an implementation detail. Focus on the branch itself: ie the
set of all revs with the same branch tag.

> 1.5 behavior for old servers: -r foo

Also bogus behavior inherited from url#id. Ignore that. Look, the whole
point of having -b options is to have something different from -r. That
difference is that we're talking about branches rather than revs.

> There are many things we could do with this. One thing we should at
> least do is expand '.' to all the branch heads of the local dirstate
> branch IF it's found on the remote (but then what if it's not?).

"when using non-branch ids with a -b, try to find the relevant branch
and use that"

If . is on branch foo, we should act as if the user typed -b foo. That's
this discussion. Whether -b foo then does something sensible or not is
irrelevant here: it should do something sensible regardless of this

> (By the way, slightly related: as for the lookupbranch function, there
> are some additional problems related to branch name encodings, which are
> also handled in addbranchrev).

Let's not muddy the waters any more than necessary with implementation
details until we can agree on a spec.

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

More information about the Mercurial-devel mailing list