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 3, 2007, 20:04 UTC
Message-ID
<20070603200431.GF6992@nan92-1-81-57-214-146.fbx.proxad.net>
In-Reply-To
<20070603151921.GB30347@artemis>

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.
Previous: Yann DirsonNext: Pierre Habouzit
Message 15 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.