Comment 2 for bug 199655

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.