Your insight is a reasonable one -- and it's where we started when we were designing SD. It quickly became apparent to us that there's a subtle but serious impedance mismatch.
It turns out that the way you want to handle merging of databases is different than how you want to handle merging of codebases.
On top of that, the obvious advantage of storing your bugs in your VCS is "branching bugs" -- unfortunately, that turns out to hurt really badly once you want to start asking questions about "what bugs are open?" and "has bug xyz been fixed."
Besides, we have a bunch of other p2p database apps we want to build that aren't sourcecode related ;)
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)
It turns out that the way you want to handle merging of databases is different than how you want to handle merging of codebases.
On top of that, the obvious advantage of storing your bugs in your VCS is "branching bugs" -- unfortunately, that turns out to hurt really badly once you want to start asking questions about "what bugs are open?" and "has bug xyz been fixed."
Besides, we have a bunch of other p2p database apps we want to build that aren't sourcecode related ;)