I have found similar insights to you. The first problem I had with using ditz on git was that I suddenly need git and ditz to just say 'hey, I'll implement thi

I have found similar insights to you. The first problem I had with using ditz on git was that I suddenly need git and ditz to just say 'hey, I'll implement this feature'. If I use trac, I just need a browser (which is clearly an advantage if you have conservative computer-pool administrators at the university :) ). Second, I don't like how git+ditz allows one to easily see OLD version data. If you forget to pull before checking your ditz, you see old data, so you don't see how I started working on the task you start working on, so we both do the same thing. That won't happen that easily if your task&bug-management lies on a webserver. This, merging and branching becomes a lot more bothersome, at least if the issue-tracker is not implemented carefully, as you said. Third, I kept running into problems, because I liked to work on certain tasks in parallel, on differnt branches (because both were interesting :) ), this did not work out well with ditz either, because comments to these tasks ended up being on different branches and this, not in a central thingie. Thus, I'd conclude that there is a certain analogy going on here: Programmers need non-programmer managers to reach peak efficiency (even though a programmer-compatible and understanding manager makes this even better), and a repository needs a good issue management tool to reach peak efficiency (even though a repository-compatible issue management tool makes this even better)