bzr status indentation of pending merges

[Ian Clatworthy]

Wesley J. Landaker wrote:

> Anyway, from the response I got in my original bug report, I think I
> understand what this is intending to show. Basically, it's showing that
> the revision that corresponds to "Whoops, fix typo" is the tip of the
> sequence of revisions that is going to be merged. If there were
> multiple indepedent *sequences* they would all be listed with similar
> indentation, and it would be easy to tell them apart, e.g.:
> 
> pending merges:
>   sequence #1 commit #3
>     sequence #1 commit #2
>     sequence #1 commit #1
>   sequence #2 comment #2
>     sequence #1 commit #1
> 
> I agree that that works to keep things delineated, but the problem in my
> mind is that the indentation plus how the revisions are being
> identified by their commit message. I know I have obviously been
> confused about this output for the entire time I've ever used bzr, and
> I'm not unfamiliar with VCS systems--I've been an early adopter on
> SVN/monotone/darcs/git/hg (as you can see from my original bug report,
> I thought it was just an output display bug).

I knew it had to be shown that way for some reason but I never
understood what that reason was. It has always confused me (but not
enough to dig into why). So thanks for this email and the detailed
explanation.

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