[RFC] make -n0 the default for log -or- make annotate and similar commands calculate merged revs

[Robert Collins]

On Wed, 2009-06-10 at 17:39 +1000, Ian Clatworthy wrote:
> Robert Collins wrote:
> > When we annotate a file, we show a dotted revno on most-or-many lines.
> > 
> > However, 
> > bzr log | less
> > /<revno>
> > 
> > Won't find that revision.
> 
> > I think this is a bug. Either annotate should do more work, so that what
> > it shows is findable, or log show be showing it.
> 
> I don't have a strong opinion on annotate's text-based UI. It's far more
> interesting to use gannotate or qannotate than the command line version.
> To begin with, there's no need to run log separately because the
> revision information is displayed the moment you click on the line.

As Martin says, showing the revisions by default in annotate would go
some way to addressing this.

> As far as log goes, I don't think having an "interesting" id - one that
> you *know* is a merge revision 99% of the time - justifies changing the
> default for log. If I run "ls ~ | grep bazaar.conf", I'm hardly
> surprised that it doesn't find it in subdirectories.

Thats a reasonable point.

> > My preference is to make -n0 the default - after some time with it as
> > non-default, I find I am typing -n0 on 3/4 times that I run log (and the
> > times I don't type it I usually have to run log again).
> 
> Progress disclosure is a principle we ought to embrace throughout the
> UI. If power users like yourself want deep searching most the time, I
> think they should add an alias, not ask for everything to be displayed
> by default. The latter becomes overwhelming IMHO, particularly for new
> users.

Do you have some studies/papers I can read on 'progressive disclosure'?
Particularly those dealing with command line usability. At the moment as
applied in bzr I have to assume that either the application or the
principle is flawed as it is giving a user experience that other bzr
developers and users are not enjoying. Command line tools are not the
same as GUI tools and my current suspicion is that progressive
disclosure is a GUI/web UI principle.

Currently bzr shows a small fraction of the commits made in the system
in log by default - commits that competing systems show - and while I
wouldn't go so far as to say I hate it, I think its a poor user
experience. Its a poor user experience because it makes having a
consistent left hand history *much* more important than it was ever
intended to be. At least one of the major poster-child users of bzr have
left hand histories that change all the time [making the -n1 behaviour
problematic at best [I think they use viz all the time to look at their
log which is probably why we haven't had a bug report]]. The 'obvious'
command (push) for two people pushing to a single branch, and two people
merging cooperatively will end up with unpleasant output in log -n1
(because integration commits like 'merged fred' will show up).

But this is theory. Point me at some research so I have the same
information you have about the principle and I will get up to speed on
it so we can talk usefully and with data.

-Rob


-------------- 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/20090610/2d191c46/attachment.pgp