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

Robert Collins robertc at robertcollins.net
Thu Jan 15 07:21:05 GMT 2009


On Thu, 2009-01-15 at 16:33 +1000, Ian Clatworthy wrote:
> So there are multiple issues here:
> 
> 1. Should we make it easy to hide/see merge revisions for each of
>    the standard log formats?

Seems like something orthogonal to formatters to me. 

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

performance is something that we should address, I completely agree.
However the 'default behaviour of log' is something that in my
considered opinion drives the perceived need for rebase in the git and
hg communities; log is the premier defacto history investigation tool,
and I think its extremely important that by default it helps people work
with the tool.

> 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

This isn't intrinsically O(history)

> * indenting according to merge depth

nor is this.

They are both defined in terms that require O(diverged history of a
merge) which is in all but the most extreme cases 10's or 100's of
revisions. This isn't the scope that our implementations necessarily
use.

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

We also have people clone massive branches without using a repository,
and serve stuff over http without using a smart server. If being the
fastest in bare-basics benchmarks makes bzr worse for users - because it
starts to hide important data, or mislead about whats been occuring,
then we're arguably making bzr _slower_ - because folk will have to
correct mistakes they wouldn't have made before.

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

I don't really like that change, but not enough to argue about it. So I
didn't. I didn't like it because I'll now have to log the branch I
merged to figure out what is included in the merge. It's going to be
painful.

-Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090115/be866227/attachment.pgp 


More information about the bazaar mailing list