Thomas Harning <harningt@xxxxxxxxx> writes: > Partly referring back to the discussion last June > (http://article.gmane.org/gmane.comp.version-control.git/49734)... has > there been any developments in the area of a BTS that can grok GIT in a > sane way? Unless you count work-in-progress Grit (http://git.madism.org/?p=grit.git) I think the answer is no. The 'after the fact commit annotation' aka git-notes are also as far as I can see abandoned. http://git.or.cz/gitwiki/InterfacesFrontendsAndTools#head-3a410db622d55b4dd88d91437d2c953f6b730542 > Main concept I see as important for a BTS grokking git: > * Capability of following branches/merges in a way that > you can see a list of bugs that affect a branch at any point > in time. > > Niceties include: > * The ability to 'distribute' this so bug tracking is as disconnected > as coding itself (great for airplane-trip coding sessions) > * Ability to watch incoming commits (suppose the BTS can 'pull' from > various sources on occasion) for messages marking a bug as > in-progress/fixed/re-opened/etc. > * Local-application GUI integration... ex: gitk/git-gui + BT BTW. you can put it in SoC2008Ideas as a project for Google Summer of Code 2008... then try to find a mentor for this project ;-) http://git.or.cz/gitwiki/SoC2008Ideas -- Jakub Narebski Poland ShadeHawk on #git -- 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
