[RFC] How various commands display revisions

[Ian Clatworthy]

Vincent Ladeuil wrote:

> Several inconsistencies have been raised in the
> https://bugs.launchpad.net/bzr/+bug/233817 comments and I find
> some more:
> 
> - the --log-format option should be available for pull, push,
>   missing and uncommit,

Agreed.

> - '--reverse' is used by missing and '--forward' by log, I find
>   '--reverse' a bit obscure and would prefer --forward
>   (presenting revisions "backward" (aka from newest to oldest)
>   being a reasonable default). Whether or not we allow --backward
>   as an alias for --no-forward may be worth it if it can be
>   hidden in the Option implementation.

Agreed about --forward in place of --reverse, though we need to
deprecate --reverse for a while rather than just replace it IMO.
I never want to suggest that someone uses "--no-forward" as an
option. :-) Please make forward/backward an item list instead of
a boolean.

> - 'update' doesn't show the merged revisions
> 
> - 'merge --preview' doesn't show what 'status --pending' will.

I don't have an opinion about the defaults here. It does seem
worth improving the flexibility of the output in these cases though.

> UI wise now, except for missing now accepting a --include-merges
> option, there is no option available to the user to decide if the
> revisions displayed should be only the mainline ones or not and
> to display the delta or not (well, sometimes -v do that).

The main command *I* care about the most is status and I'd like
us to consider changing how we display non-mainline revisions there.

By default, I'd like status to show just the *merge tips* if there
are any. I'd like status -v to show the full list of merge revisions.
In particular, when merging from trunk into a feature branch right
now, 'bzr status' can show 100s of revisions and they are just
noise. I find myself constantly using --no-pending in this case to
see the list of files that has since scrolled off the screen. :-(
Showing just the tips will also be *much* quicker.

For consistency, I guess other commands should do the same: show
just the merge tips by default and show all merge revisions if -v
is given.

> Going back to each command now it may worth deciding if we can
> find ways to add some options without having to provides all log
> options to every command:
> 
> - log: the revision range is explicit, missing options: --delta
>   (currently available as -v), --include-merges (implicitly tied
>   to formats)
> 
> - merge[1]: the revisions range is implicit, missing options:
>   --log-format, --delta, --include-merges[2], --forward, --show-ids
> 
> - missing: the revisions range is implicit, missing options:
>   --forward (currently --reverse), --delta (currently available as
>   -v),
> 
> - pull: the revisions range is implicit, missing options:
>   --log-format, --delta, --forward, --include-merges (currently on
>   by default when using -v), --show-ids
> 
> - push: the revisions range is implicit, missing options:
>   --log-format, --forward,--delta, --include-merges (currently on
>   by default when using -v), --show-ids
> 
> - status[3]: the revision range is implicit, missing options:
>   --log-format, --forward,--delta, --include-merges (-v do nothing
>   ?),
> 
> - uncommit: the revision range is explicit, missing options:
>   --log-format, --forward (really ?), --delta (currently available
>   as -v), --include-merges, --show-ids
> 
> - update: the revisions range is implicit, missing options:
>   --log-format, --delta, --forward, --include-merges (currently on
>   by default when using -v), --show-ids

So it looks like adding support for --log-format and --show-ids
would be a good next step, improving both consistency and
functionality.

> Also note that I'm not proposing to change the actual *default*
> behaviors, but more trying to find if we need to add options
> (possibly by making --log-format richer) or make verbose a bit
> more progressive (-v, -vv, -vvv, etc).

If we want total consistency, I'm sure we will need to change
some current defaults. I think that consistency for the sake of
it would a mistake though. Before we change any given command's
default, we should convince ourselves that it's the right thing
to do for the users of that command.

Ian C.