bzr status shows pending merges with incorrect indentation

Hi Wesley,

Thanks for taking the time to file this bug! I'm afraid that the behaviour you describe is actually intentional, and visualises accurately what happens in a merge. When you merge in a branch, you are in fact merging in the last revision of the branch (the tip), which is indented 2 spaces. This revision depends on all of the other revisions, which won't actually be merged into the mainline (but will be part of the dependencies of the mainline) and so they are indented 4 spaces. This might be more obvious if you use the bzr-gtk plugin's 'bzr viz' command to examine the history in a more graphical manner.

As such, I'm marking this bug invalid. If you think that something different really should be happening, then this discussion would be better continued on the mailing list, which can be found at https://lists.ubuntu.com/mailman/listinfo/bazaar.

Thanks,

Dan

Hmmm... I guess I get what you are saying, but I'm still not sure it makes sense -- at least, it's not totally clear to the user what's going on. For instance, in the example I gave, after committing the merge, the revisions that are assigned are:

336 (the merge itself)
336.1.5 Wesley J. Landaker 2008-03-07 Added informative message about what ...
336.1.4 Wesley J. Landaker 2008-03-07 Simpler naming for prebuild instances to ...
336.1.3 Wesley J. Landaker 2008-03-07 Interactive progarm now supports all three ...
336.1.2 Wesley J. Landaker 2008-03-07 Refactored phase shifting code. Added ...
336.1.1 Wesley J. Landaker 2008-03-07 Note that PSDONE is latched.

I guess what you are saying kind of makes sense in that the first listed revision is the "tip" of that sequence of merges, and if I had multiple unrelated *sequences* of merges pending, then the indentation would help show that those lines of development were separate.

I won't argue with the resolution, since it sounds like this is indeed a design decision as opposed to an oversight--it's not too terrible to deal with either way. I for sure thought this was a bug since day 1 of using bzr. ;)

I'll have to think about if I have any suggestions about how this could be made more clear to the user, but if I have any insights maybe I'll bring it up on the list as you suggestion.

Anyway, thanks for the response and clarification.