Holger Hellmuth <hellmuth@xxxxxxxxxx> writes: > Am 06.11.2014 um 19:45 schrieb Junio C Hamano: >> This is a tangent, but I personally do not think "ticket" meshes >> very well with "commit". If you already know which commit was >> problematic, why are you annotating it with a ticket before >> reverting it first? > > I would expect a ticket to be annotating the commit or version tag > where the bug was found, which usually isn't the commit where the bug > was introduced. You could arrange your "tickets" in such a way, but in general, the way you organize your data should match how the data is expected to commonly be accessed. If somebody finds a bug when the version he happened to be using was v1.8.5-9-g144d846, do you mean to attach that ticket to that exact commit? Or do you use v1.8.5^0 (i.e. the closest tagged version) after making sure that it is not a commit between these two that introduced it as a new bug? Either way, I do not see how such an arrangement is the most convenient way to organize the tickets and ask questions such as "what are the known, untriaged, or unresolved issues in v1.8.5?", "what are the issues that didn't exist in v1.7.0 but appear in v1.8.5?", "what are the outstanding issues around refs handling that are the highest priority?", etc. With your arrangement of data, any of the common questions I think of asking would require a linear scan of a commit range, followed by an enumeration and parsing of all the notes attached to the commits to answer. So I would have to say that your expectation makes even less sense than annotating an exact buggy commit with a note saying what is broken by it. -- 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