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

[Sune Foldager]

On 22-04-2010 23:27, Matt Mackall wrote:
> On Thu, 2010-04-22 at 21:49 +0200, Sune Foldager wrote:
> 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"

Yes...  but the only sensible thing to do, IMO, would be to lookup those
revs remotely. We *currently* can't, as I am sure you're already tired
of hearing me saying ;-). I don't like the idea of looking them up
locally; see below.

> That statement also answers just about all the questions you could have
> about the behavior details.

What details? In the current or proposed behavior? I know how the
current one works, of course, since I wrote it. I also *think* I know
how you would like it to work...although not 100% sure... but I don't
think I agree with it. But we shall see.

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

Uhm.. the above makes absolutely no sense to me :/. As we agreed on at
the sprint, # now also means branches first, falling back to revs.
Currently, this is what -b does as well. I agree that even if we change
-b, we should probably keep # behavior the way it currently is.

> 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
> head"
>  "when we pull -b tag, we look up the tag, then pull all the resulting
> rev"

But this table doesn't say anything about how we determine whether or
not, -b foo, foo is a rev locally, remotely or a branch in either of
those places. Actually, I really don't understand that table at all, I'm
sorry to say :( (and showing it to hstuart, he didn't either, so it
might be a danish thing). But as long as you agree with my 'table', at
least that's one we both understand.

I prefer to think and talk about this algorithmically, instead, though.

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

In my 'table' I just describe the mechanics in the code, not the user
experience. That said, I do think many users will care about it :-p.

>> 1.5 behavior for old servers: -r foo
> 
> Also bogus behavior inherited from url#id. Ignore that.

It's not inherited from url#id. I wrote it de novo. But it's identical
to the previous url#id behavior, yes. At any rate, I was just describing
the current behavior; not saying that I want it to be that way.

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

Yes... hmm... of course I agree with that. That's why I suggested the
option initially (at the sprint.. and probably on IRC some times before
that). Translating into -r head1..n is just an easy way to implement
that behavior.

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

Certainly. I just don't think starting to look-up stuff locally for a
pull makes sense (apart from '.'). I think it will confuse users a lot
more than simply failing. Like pull does if it gets a -r blah where blah
doesn't exist on the remote.

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

Yes, I don't think we're disagreeing on that. There is a bug in -b .
since it doesn't exactly behave like -b foo for dirstate branch foo. It
should. I'll fix that first, it's pretty trivial.

/Sune