On Wed, Sep 10, 2008 at 04:16:30PM +0200, Stephen R. van den Berg wrote: > >Once you have this information, it is not difficult to maintain a > >berk_db database which maps a particular Bug identifier (i.e., > >Red_Hat/149480, or Debian/471977, or Launchpad/203323) to a series of > >commits. > > This is nice, I admit, but it has the following downsides: > - It is nontrivial to automate this on execution of "git cherry-pick". Maybe a cherry-picking hook? > - In a distributed environment this requires a network-reachable bug > database. Use a distributed bug tracking system (DBTS). > - A network-reachable bug database means that suddenly git needs network > access for e.g. cherry-pick, revert, gitk, log --graph, blame. Use a DBTS. > - Network queries for commits containing references kind of kills > performance. Use a DBTS. > - Some backports don't have entries in a bug database because they > weren't bugs to begin with, in which case it becomes impossible to add > an identifier to the commit message after the fact. Use a DBTS, since then you can generally make up a new UUID on the spot. > - It relies heavily on tools outside of git-core, which raises the > threshold for using it. True. But maybe Ted is on to something here. Rather than adding the information to the commit object itself, why not maintain a separate mapping, but keep it _within git_. That is how most of the DBTS's work that I have seen. Maybe it is possible to implement some subset of the features in a tool that could become part of core git. There was a proposal at some point for a "notes" feature which would allow after-the-fact annotation of commits. I don't recall the exact details, but I think it stored its information as a git tree of blobs. You could choose whether or not to transfer the notes based on transferring a ref pointing to the notes tree. I'm not sure how applicable this is to your problem, but if you want to investigate you can find discussion in the list archive under the name "notes". -Peff -- 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
