[RFC] proposed changes to log UI

[Ian Clatworthy]

John Arbash Meinel wrote:

> Certainly, IMO, 'bzr log -r XXX' should show a single revision, while
> "bzr log -c XXX" should show the revision and what other revisions it
> merged. I'm not sure if we could get away with switching them or not.
> 
> (A lot of the sys admins seem to use 'bzr diff -c' a lot, and want to
> have a compatible 'bzr log -c'. It may just be that -c didn't work for
> 'bzr log', and they don't care if it shows extra revisions or not.)

That's my guess - users now expect bzr log -cX to work. I think it
ought to behave exactly as log -rX does though.

After more reflection, I'm warming to the current approach, i.e.
the decision to show merged revisions ought to be a function of
the log formatter selected. The problem is that we don't have a
standard formatter than produces long-like output for just
mainline revisions. I'd like to add one along those lines.
My suggested name is "linear". (It ought to perform identically
to "short".)

>   a) I like --short a lot.
>   b) I feel like we should be splitting out the differences from --short
>      and --long
>      So you have a way to say "bzr log --only-mainline
>      --verbose-revisions", which gives the --short revisions, but the
>      --long formatting.

I think --linear achieves that. It may even make a better default
than --short.

>> 3. If a revision range is given and the log format only
>>    supports mainline revisions, I don't want to check that
>>    the revisions are on the mainline by default. This check
>>    is O(history) and, IMO, ought to only be done if a
>>    new option (--strict say) is specified.
> 
> I guess I don't quite understand what you mean by this one. If I do:
> 
> bzr log --short -r -10..revid:XXXX
> 
> What should be displayed? How do we decide the revision numbers? Do we
> just start walking the left-hand history of XXXX or do we walk the
> history of branch.last_revision() and expect to run into XXXX?

Right now, I'm walking the mainline and complaining if I don't
run into XXXX. If I find XXXX, I walk back to the beginning and
complain if I don't run into the lower limit.

Conceptually though, I think your first suggestion is better:
start at XXXX and walk the left-hand history, expecting to find
the lower limit. After all, "log -r1.2.1..1.2.11" ought to
be handled by all formatters IMO, not just those supporting
the display of merge revisions.

Ian C.