bzr status indentation of pending merges
Harald Meland
harald.meland at usit.uio.no
Thu Mar 27 13:37:38 GMT 2008
[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
More information about the bazaar
mailing list