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

Sune Foldager cryo at cyanite.org
Thu Apr 22 14:49:06 CDT 2010


On 21-04-2010 02:08, Matt Mackall wrote:
> On Wed, 2010-04-21 at 00:58 +0200, Sune Foldager wrote:
>> IF we could have: 4' Lookup remotely and use its branch, I would have
>> prefered that over 4; but we can't.
> 
> We can't? I think you mean "it needs implementing".

Well, I mean "it needs careful thought, design, coordination with other
protocol changes and then development". So I thought we'd postpone it
for now.

> 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). Second, -b and
# behave 100% identically 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


1.5 behavior for old servers: -r foo


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

Another thing would be replacing the 'anything else' action with
something else. My preference is probably 'fail', after giving it thought.

I'd love for other crew members to chime in. Or is only Sune Foldager
and Matt Mackall interested in this?

I am less and less convinced that it makes much sense to unify this with
log -b.

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

/Sune


More information about the Mercurial-devel mailing list