On Tue, 08 Apr 2008, Colin Watson wrote: > Why wouldn't you just want to copy the history of the bug you named > in the clone command (as Marcus observed, he did name a particular > bug explicitly), and just remove the state bit that indicates that > it's merged with another bug? If you keep all the history then it'll > still have a reference to its merge partners in the log.
You can't just copy it, because you also need to indicate that the cloned bug has been unmerged, otherwise the history is confusing to read. [This latter bit blocks on finishing abstracting out control.] This is one implementation possibility, but because it loses any messages which were sent to the other cloned bugs it's not the optimal one without the secondary change(s) below. > Unless I've misunderstood you, I'm not convinced about this. The > start of such bugs would be extremely confusing to read. > > The variant of this I'd prefer would be that mails sent to merged > bugs should be appended to the bug logs for all the merge partners > (allowing duplicates to be hidden by the display engine in the usual > way), but that the initial distinct history of the merged bugs > before they were merged should be preserved. Trying to glom them > together would be awful. This means that bugs which are merged later will be less useful than bugs which are merged earlier, which is suboptimal. I think this may be a workable start until the proper solution is implemented, though. Putting them together would require changing the way that we display logs to respect threading but that's something that we need to do anyway. Don Armstrong -- Q: What Can a Thoughtful Man Hope for Mankind on Earth, Given the Experience of the Past Million Years? A: Nothing. -- Bokonon _The Fourteenth Book of Bokonon_ (Vonnegut _Cats Cradle_) http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
