Jeff King wrote: >On Wed, Sep 10, 2008 at 04:16:30PM +0200, Stephen R. van den Berg wrote: >> 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? Yes, that works, but it is non-trivial, especially since it needs to work for gitk, log --graph, blame and revert as well. >> - In a distributed environment this requires a network-reachable bug >> database. >Use a distributed bug tracking system (DBTS). If it were part of git-core, that would work. >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. Interesting thought. >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. The idea is nice, but if we were to use it to store the origin link information, the following happens: - Origin link information is rare. - Yet during a log/gitk/blame run the information might need to be queried for at every commit. - Since in most cases the origin information does not exist, this will cause misses to fill the dentry cache for directory lookups, and thus killing performance. - In order to make this efficient, a different database lookup system is needed that is fast for misses. Whereas if the information is part of the commit, it costs nothing in the typical case (no origin information present). -- Sincerely, Stephen R. van den Berg. "Am I paying for this abuse or is it extra?" -- 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