Am 11.11.2014 um 18:17 schrieb Junio C Hamano:
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.
[...]
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.
Not less sense, because with tickets attached to the exact buggy commit
one would have the same problems answering the questions above. I don't
dispute that tickets and commits don't mesh, it was the reason that you
gave the first time that didn't sound right. Sorry if I have wasted your
time, but looking at it from the management side removed any lingering
doubts for me that there might be a benefit to an integration, even if
some sort of indexing or database was used.
--
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