Merge requests that occur on revisions before the revision tagging a bug shouldn't be shown on a bug page

Is this for the case of a branch that was linked to other bugs with other merge requests and is now linked to a later bug with a different merge request? Am I understanding that correctly? Can you point me at a bug as an example of this?

On Tue, 2010-04-06 at 17:07 +0000, Deryck Hodge wrote:
> Is this for the case of a branch that was linked to other bugs with
> other merge requests and is now linked to a later bug with a different
> merge request? Am I understanding that correctly? Can you point me at
> a bug as an example of this?

Not with any permanence as it'll change rather rapidly. I think I can
describe it better. I think they key is that we're reusing branches,
not having one branch for one bug (or even several).

So I have a packaging branch that we use upstream. I has, and will
continue to fix bugs. It also gets merged into the distro packaging
branch fairly regularly. Each time that happens it's associated with a
merge request.

If between version 8 and 9 I fix a couple of bugs those get associated
with the packaging branch (debcommit does this if they're in the
debian/changelog). So then in the bugs that are fixed in revision 9 the
packaging branch shows up. But, since that branch was merged to the
distro packaging branch at version 8, the merge request also shows up
saying that the branch has already been merge. And that isn't the case
for the bug in question because it wasn't fixed until revision 9.

[Expired for Launchpad itself because there has been no activity for 60 days.]

If I understand correctly, this is a real bug. Suppose I have a long-lived 'doc' branch.

I fix bug A, commit the revision fixing it, propose that and merge it.

I then fix another bug B, commit the revision fixing it, and propose that merge. The mp page currently lists both A and B, but A is irrelevant.

lp:~mbp/bzr/doc and lp:~mbp/bzr/trivial probably exemplify this.