"Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes: > The latter (build and test log) would generally be very large. > We would *not* want to cluster them. But we might want to store > next to the commit a very small pointer to the note itself. Such > as the note's SHA-1. Or its offset within the packfile's index. > This would make locating those notes very cheap, while not having > a huge impact on the common case of commit traversal. > > Likewise we might want to pack a tag's SHA-1 alongside of the commit > it points at, as parsing the commit would immediately give us all > annotated tags that refer to that commit. Tags are (usually) few > and far between. But tools like git-describe are commonly used and > would benefit from not needing to build the commit->tag hashtable. I am not so sure. It is a good idea to have an internal API that takes an object and gives back a set of objects (be they notes to commit or tags point at object) related to it, but you need to always deal with loose objects and v2 packs, so you will have to traverse all the tags and find what they point at _anyway_ to implement the API. Having a specialized table in v4 does not mean you can look at that table and nothing else, so I do not immediately see a gain. - 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
