bzr status indentation of pending merges

[Harald Meland]

[Andrew Bennetts]

> Ian Clatworthy wrote:
> [...]
>> > Anyway, *I* now understand what's being displayed here, and why, so I
>> > can live with it. But I wonder if this is confusing or potentially
>> > confusing to anyone else, especially new users, and if there isn't an
>> > easier way to show the same information without confusion.
>> > 
>> > For example (maybe a bad idea, just illustrating that there are
>> > alternatives) add an astrisk on the first one in a sequence , instead
>> > of indenting the rest:
>> > 
>> > pending merges:
>> >   * sequence #1 commit #3
>> >     sequence #1 commit #2
>> >     sequence #1 commit #1
>> >   * sequence #2 commit #2
>> >     sequence #2 commit #1
>> 
>> I like this more than our current output. Here's another option:
>> 
>> pending merges:
>>     sequence #1 commit #3
>>     sequence #1 commit #2
>>     sequence #1 commit #1
>>     --
>>     sequence #2 commit #2
>>     sequence #2 commit #1
>> 
>> In the common case where the merge only has one sequence, it would then
>> display what you and I (at least) expected.
>> 
>> From an implementation perspective, my guess is that it's an easy change
>> to make. The bigger question is whether others agree we ought to make it.

> I think we should do something.  It bugs me that the indentation in
> the status output doesn't correspond to the indentation of same
> revisions in "bzr log" (if I do commit the pending merges).

Apart from the "last revision from branch has different indentation
than the other pending-merge revisions" issue, I also kind of find it
strange that the listed revisions have been flattened.

That is, if I merge from a branch X that contains merges of another
branch Y, the list of pending merges can use the same indentation for
revisions from X and from Y.

This also differs from how those revisions will be displayed by "bzr
log" after committing the merge.

> Or perhaps it would be better to spell out the case of multiple merges more:
>
> pending merges:
>   merge 1:
>     sequence #1 commit #3
>     sequence #1 commit #2
>     sequence #1 commit #1
>   merge 2:
>     sequence #2 commit #2
>     sequence #2 commit #1

I like this.  Would it be possible to include the branch nick of the
merged-from branches on the "merge N" lines?

Also, am I the only one who thinks that the list of pending merges
might be easier to read if it was displayed in forward chronological
order, i.e.

  merge 1 (from bzr.foo):
    bzr.foo commit #1
    bzr.foo commit #2
    bzr.foo commit #3
  merge 2 (from bzr.bar):
    bzr.bar commit #1
    bzr.bar commit #2

I'm not sure how new revisions that originate from merges of
subbranches into bzr.foo and bzr.bar ought to be displayed; maybe the
sequence for each merge could have an optional final line saying
something like

    bzr.baz commit #4
    (plus 10 new revisions from other branches)
  merge 3 ...

, and maybe the --verbose switch could incorporate those merges of
merges to correspond with how bzr log would look.

> Or more radically, I'd probably be satisfied with this output by default:
>
> pending merges:
>   sequence #1 commit #3
>     (and 2 others)
>   sequence #2 commit #2
>     (and 1 other)

Doing things like this would likely exacerberate the same problem that
has just been alleviated in the pqm-submit plugin -- the last commit
on a branch rarely describes the purpose of that branch.

> I'm thinking here of when I merge a week or two's worth of changes
> from bzr.dev into some branch in progress Ñ I usually don't care
> about the details of the merges, just a sense of "yes, I merged a
> bunch of revisions."  I'd also expect a --verbose switch would give
> the full listing, like what we see today.  This proposal would also
> have the happy effect of making displaying the pending merges output
> much cheaper...

Is the slowness of displaying pending merges *inherently* slow, or is
this among the performance problems that are being worked on?  If the
slowness can be fixed, I like the non-truncated display better.
-- 
Harald