[RFC] proposed changes to log UI

[Martin Pool]

2009/1/13 Ian Clatworthy <ian.clatworthy at internode.on.net>:
> As currently implemented, log is O(history). I'd like
> to make some UI changes so that it can be refactored
> to use a more intelligent approach by default for
> common operations.

I think that's a good approach; we can certainly look if there's
something easier that will satisfy the user, as well as looking for
ways to make the current behaviour faster.

Some users at some point are not going to discover possibilities
beyond the default: log --line scales much better than the default,
but most people are going to compare our performance on the default
log operation.  Conversely, if we defaulted to only showing the
mainline or linear revisions, then people might get the idea that we
don't track merge information.

You can tackle this headon by adding information to the command help:
that --line is faster or that you can get the merge graph by
--include-merges.  That might be the lowest fruit at the moment.

At the moment we have the full nested view and the linear view.  We
could also have a "flattened" view that includes merged-in revisions
in topologically sorted order.  That may be easier to do quickly.

> 1. If a single revision is given, I just want to log it,
>   not all the revisions merging it to mainline. If you
>   want the latter, perhaps -v ought to be required?

That might be a reasonable default; or at least that function should
be accessible.  It seems like there are in fact two orthogonal options
beyond that:

 * show the path by which this revision was merged in to the mainline

 * show the other revisions newly merged to mainline by this revision

At least the first would also make sense when selecting revisions
touching a file.

> 2. I want to make --short the default format. (Many of us
>   do this already as it provides the best signal:noise
>   ratio and performance for most of the workflows that
>   Bazaar encourages.)

I'd support that, as long as the help is clear about how to get more data.

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

That makes sense to me too.

-- 
Martin <http://launchpad.net/~mbp/>