Jeff King wrote:Yes, that works, but it is non-trivial, especially since it needs to work for gitk, log --graph, blame and revert as well. If it were part of git-core, that would work. Interesting thought. 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Winkler, Tomas | RE: iwlwifi: fix build bug in "iwlwifi: fix LED stall" |
| Jeff Chua | 2.6.27rc1 cannot boot more than 8CPUs |
git: | |
| David Miller | [GIT]: Networking |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Andrew Dickinson | tx queue hashing hot-spots and poor performance (multiq, ixgbe) |
| Hugh Dickins | Re: [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin" |
