[RFC] How various commands display revisions

[Martin Pool]

On Thu, Sep 25, 2008 at 4:27 PM, Ian Clatworthy
<ian.clatworthy at internode.on.net> wrote:
>> - '--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.

Agree, on both counts.

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

+1, both on simplicity and speed.

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

Hm, I think it would be a bit odd if missing, push, pull, log and
uncommit didn't show all the revisions, but I could be persuaded.

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

I think so, though I think (to state the obvious) it would be good to
do this by making the code more common between them.

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

Right, I think changing defaults is ok as long as we're pretty sure we
won't need to change it again, and also that the old behaviour can
still be obtained.

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