[MERGE] New log formats controlling the display of merge revisions

[Ian Clatworthy]

Matthew D. Fuller wrote:
> On Thu, Jan 15, 2009 at 11:29:57AM +1100 I heard the voice of
> Robert Collins, and lo! it spake thus:
>> On Thu, 2009-01-15 at 09:33 +1000, Ian Clatworthy wrote:
>>> This patch changes the default log formatting so that merge
>>> revisions are not displayed. The old 'long' format is now called
>>> 'long+' instead. Matching 'short+' and 'line+' formats are also
>>> provided for consistency.
>> This seems like a bad idea to me; I depend on merged revisions when
>> using log; git and hg both show merged revisions; whats the reason
>> for doing this?
> 
> FWIW, I agree.  If nothing else, this seems like a support nightmare.
> I use --short most of the time, but I would be quite unpleased if I
> found that 'bzr log' no longer showed all the revs in my branch.  It
> comes down VERY hard on the "mainline is special" side, to the point
> of declaring "non-mainline is meaningless and unnecessary", and I
> seriously doubt that as an efficacious default posture.

So there are multiple issues here:

1. Should we make it easy to hide/see merge revisions for each of
   the standard log formats?

2. What should be the default behaviour of log?

I can't see an argument against 1, though the best naming is up for
debate. If we feel 'long' must act exactly as it does now and can't
be changed for backwards compatibility reasons say, then the three new
formats could be called 'long-', 'short+' and 'line+' say.

Once 3 * 2 formats exist regardless of their naming, we need to pick
the best default. When I proposed short as the default a few days
ago, the response was overwhelming positive, *despite* the fact that
short never shows merge revisions. It seems that a large number of us
use short most of the time. It would be good to understand the driver
behind that. Is is because of:

* hiding the merge revisions means just the mainline is displayed?
* conciseness of revision display?
* performance?

In my case, it's all of the above.

I'm still comfortable with making short the default, though making
it "linear/medium/long-/whatever-we-call-it" feels less of a UI
disruption.

More broadly ...

Martin Pool has stated that our default UI is on the table if
it causes slow performance for large projects. There are two
aspects to the display of merge revisions in log that are O(history)
and arguably will remain so:

* dotted revision numbering
* indenting according to merge depth

Both are great features of our UI and, speaking for myself,
I'm not prepared to lose either of them. I don't think we
need to either - we just need to turn the display of merge
revisions off by default so that log *out-of-the-box* is fast.
Every single time bzr is benchmarked on a large project, log
is highlighted as mega-slow vs git/hg. In extreme cases, it's
blocking adoption of or migration to Bazaar.

BTW, I also feel that "mainline is special" is a key feature
of Bazaar's overall user model. I understand that not everyone
agrees with this perspective. That doesn't make non-mainline
meaningless/unnecessary, just less interesting. Hiding less
interesting things *by default* is good UI design. My recent
change to status (hide non-tip pending merges) is another
example of adopting this UI design principle.

Can you explain more about why you feel changing the default
behaviour of log will be a support nightmare? I agree that the
help for log is sparse but that's easily fixed.

Ian C.