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

[Matthew D. Fuller]

[ Some^WMost parts of this email come across rather strident and
  combative.  I don't really intend them that way, I'm just short on
  time to work out better phrasings.  Try not to read too much anger
  into it   :]


On Thu, Jan 15, 2009 at 04:33:09PM +1000 I heard the voice of
Ian Clatworthy, and lo! it spake thus:
> 
> 1. Should we make it easy to hide/see merge revisions for each of
>    the standard log formats?

Yes.  I semi-regularly wish for more granularity of control over what
log displays.


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

The first two for me.  But that's because of two explicit choices; the
explicit choice to work in a way that the mainline has all the
necessary information, and the explicit choice to only see that
information much of the time (note that 'log' is still --long for me,
and I use it often; I just use --short more).  --short is, at base, a
crippled log.  It's just crippled in a good way, that's rather useful
in a lot of cases.

Available evidence suggests, though, that it's not an entirely natural
way for new users to work, and theoretical musings about project
structure suggest the choices can be extremely difficult ones to make
about a lot of large or well-distributed projects.

As for the third, on many branches, --long isn't that slow, and where
it is painful, --short hasn't (IME) been enough faster to make the
difference.


> More broadly ...
> 
> Martin Pool has stated that our default UI is on the table if it
> causes slow performance for large projects.

There's a difference between "This UI feature necessarily makes things
slower" and "various deficiencies make this UI slow".  I suspect that
this case is far more the latter than the former, and changing
(weakening, IMO) the UI to paper over the problems isn't the right
direction.

Look, we do more with log, because of the revno and because of the
structuring of mainline vs. remote, than git or hg.  It will
necessarily always be slower.  I refuse to believe, though, that
either of those things necessarily call for a 100% or 500% or 1000%
performance difference.  If we're 5% slower or 10% slower, I don't
think anybody will care.

And if we make a log formatter that doesn't do that (bzr log --git),
that overhead shouldn't even exist in the first place.  bzr shouldn't
inherently need to do any more work than git to do that; if it does,
that points at a deficiency in the code that needs to be rectified,
not a need to cut back on the UI.


> Every single time bzr is benchmarked on a large project, log is
> highlighted as mega-slow vs git/hg.

Are you prepared to trade that for "Every single time bzr is
benchmarked on a large project, log is highlighted as mega-broken vs
git/hg because it doesn't actually show the revs in the history"?


> BTW, I also feel that "mainline is special" is a key feature of
> Bazaar's overall user model.

As do I.  It's one of the rather short list of things I *can't* get
anywhere other than bzr, and exerts a very strong hold that would tend
to keep me on bzr even in the face of absurd shortcomings everywhere
else[0].

In fact, a lot of the other things on that list are consequences of,
or capabilities in support of, that distinction.  It's not _a_ key
feature, I would say it's _THE_ key thing that makes bzr something
other than a slow clone of git.  Having, using, and extolling that
feature, though, doesn't necessitate making it harder (or impossible)
to use bzr without it.


> 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 think these are very different cases.  I don't look at the pending
merges in status to figure out what happened; I do it as a quick check
that I've done what I expected.  Heck, it's in --line style; there's
not enough information in that to spit at for any sort of detail.  I'm
at least cautiously in favor of it not for performance, but for
_convenience_; it means I can see the status of the files, which is
the primary thing I care about with status.

Log is a whole different ballgame.  Every other VCS on the planet
interprets 'log' to mean 'show me everything'[1].  Limiting the
display, whether to given files, or given revisions ranges, or given
revision slices, always requires adding arguments to describe how to
limit it.  I disagree with showing a slice of revisions by default for
the same reason I'd disagree with "-r-10.." as a default.  Having to
supply an arg for log to actually show the whole log is just an
--unbreak-me.


> Can you explain more about why you feel changing the default
> behaviour of log will be a support nightmare?

Well, the above has all sorts of abstract reasons.  For a concrete
one,

Q: What happened to this revision?  It's not in log, but merge says
   there's nothing to do.
A: Oh, you have to use the magic decoder log --really-show-me-the-revs



[0] Note the subjunctive before you pounce on me about the absurd
    shortcomings.

[1] Well, with CVS and friends 'everything' is defined in a pretty
    circumscribed way, but it's still 'everything' in the tool sense.


-- 
Matthew Fuller     (MF4839)   |  fullermd at over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
           On the Internet, nobody can hear you scream.