One thing that I just thought about is how such a system would play with eg. StGIT. Precisely, if I stick a BTS note (found/not-found probably makes no sense here, so that'd mostly be fixes/enhances notes) to a given version of an StGIT patch, I probably want the BTS to be able to tell that the next version of the patch "probably has" the same note - if a given patch fixes a given bug, I infer the patch is primarily written as a fix for that bug, so later revisions of the patch (eg. cleanups) would also fix it. But maybe we'd want the patch author to explicitely make such an assertion, in case a cleanup would have broken the fix - both options could be useful in different cases. Currently, old versions of an StGIT patch are only available through StGIT patchlogs, which are not ancestors of later versions of the same patch. That is, even the "subsequent versions inherit notes" policy would need extra StGIT-aware stuff to work. This may be something to keep in mind here - but that issue could also be seen as belonging to the more general (and with ongoing work) aspect of git/StGIT interactions. Even better if the 2 ongoing reflexions cross-fertilisate :) Best regards, -- Yann. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
