Petr Baudis <pasky@xxxxxxx> wrote: > On Wed, Aug 20, 2008 at 07:13:26AM -0700, Shawn O. Pearce wrote: > > I've thought about starting a code.google.com project just to use > > the issue tracking system there. > > I have been thinking about issue tracking for some of my projects too, > but I'm wondering, does anyone have a comprehensive picture of the state > of the Git-supporting issue tracking tools, especially those that keep > the tracked issues in a Git repository as well? > > http://git.or.cz/gitwiki/InterfacesFrontendsAndTools#head-73b23f376ebd0222d1e4b08f09158172aa34c24f > > has three, but two of them are in Ruby, which is rather discouraging. > But Cil (in Perl) is already "self-hosting", so it might be well usable? Cil is interesting. I'm concerned about keeping the state in tree with the repository though in a distributed development team. If I mark the status of an issue in a branch that isn't ready for mainline how do I share that status update with everyone else? I have to put it into a branch somewhere, no big deal. repo.or.cz is pretty good at publishing things. But do that now for 5 developers working on 10 or 20 different branches at once. We'll have status updates all over the place and Marek's desire to see what we are each working on (to reduce wasted effort and perhaps help each other out more) still isn't met. This is the number one reason a DIT (distributed issue tracker) isn't available. Nobody has solved the hard technical problem of making it easy to distribute the state changes, yet still provide a reasonably current global view of the issue status. Perhaps running Cil in its own egit-cil.git repository would get us what we neeed. I looked at the code and its pretty clean, but I didn't see how merges of the .cil database work. -- Shawn. -- 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