git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [RFC] git integrated bugtracking

From
Yann Dirson <ydirson@altern.org>
Date
Jun 4, 2007, 22:03 UTC
Message-ID
<20070604220308.GJ6992@nan92-1-81-57-214-146.fbx.proxad.net>
In-Reply-To
<20070603151921.GB30347@artemis>

Another aspect that I have not seen discussed yet is the handling of testcases that expose a bug, and which are usually integrated as non-reg tests afterwards.

If we're going the way of using git-note's, we can easily link the commit which adds the testcase to the non-reg testsuite.

But we could be interested in running the testcase against an arbitrary commit, thus allowing some sort of automated bisect (modulo applicability of the testcase to other commits, which may cause false negatives, but also false positives, and thus may need to be hand-driven or at least hand-reviewed).

For this, however, would it be sufficient to have the testcase committed somewhere in the history tree ? Our hypothetic automatic bisect tool could cherry-pick that commit and run the testcase, but at would place an arbitrary restriction of "one testcase per commit", which would probably a bad idea.

And having the annotation point to the blob does not seem a good idea either, at least because currently in git tools we have test scripts that excercise several testcases each.

Even an annotation to both a commit and a blob changed by that commit would not be sufficiently accurate, when several testcases are added to the same script in a single commit.

Another options would be to embed the testcase in an annotation: I can't really see that being used, since that would duplicate the testcase. That makes me wonder whether it would not be required to have testcases described in seperate files ?

Best regards,
-- 
Yann.
Previous: Pierre HabouzitNext: Pierre Habouzit
Message 17 of 46 in “[RFC] git integrated bugtracking”
  1. Pierre HabouzitJun 3, 2007
  2. Yann DirsonJun 3, 2007
  3. Pierre HabouzitJun 3, 2007
  4. Michael PooleJun 3, 2007
  5. Pierre HabouzitJun 3, 2007
  6. Johan HerlandJun 3, 2007
  7. Pierre HabouzitJun 3, 2007
  8. Matthieu MoyJun 3, 2007
  9. Pierre HabouzitJun 3, 2007
  10. david@lang.hmJun 3, 2007
  11. Pierre HabouzitJun 3, 2007
  12. david@lang.hmJun 3, 2007
  13. Yann DirsonJun 3, 2007
  14. Yann DirsonJun 3, 2007
  15. Yann DirsonJun 3, 2007
  16. Pierre HabouzitJun 3, 2007
  17. Yann DirsonJun 4, 2007
  18. Pierre HabouzitJun 4, 2007
  19. Linus TorvaldsJun 3, 2007
  20. Pierre HabouzitJun 3, 2007
  21. Martin WaitzJun 3, 2007
  22. Rogan DawesJun 4, 2007
  23. Yann DirsonJun 3, 2007
  24. Pierre HabouzitJun 3, 2007
  25. Pierre HabouzitJun 9, 2007
  26. Jakub NarebskiJun 9, 2007
  27. Daniel BarkalowJun 10, 2007
  28. Johannes SchindelinJun 10, 2007
  29. Martin LanghoffJun 10, 2007
  30. Junio C HamanoJun 10, 2007
  31. Martin LanghoffJun 10, 2007
  32. Pierre HabouzitJun 10, 2007
  33. Martin LanghoffJun 10, 2007
  34. Pierre HabouzitJun 11, 2007
  35. Martin LanghoffJun 11, 2007
  36. Jan HudecJun 10, 2007
  37. Jon LoeligerJun 11, 2007
  38. Guilhem BonnefilleJun 12, 2007
  39. Jan HudecJun 10, 2007
  40. Martin LanghoffJun 10, 2007
  41. Jan HudecJun 10, 2007
  42. Matthieu MoyJun 10, 2007
  43. Pierre HabouzitJun 10, 2007
  44. Pierre HabouzitJun 10, 2007
  45. Pierre HabouzitJun 10, 2007
  46. Rogan DawesJun 4, 2007

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.