Hi,
Shawn triggered some well needed thinking on my part about the notes
implementation. At the moment, we have flat directory structure, and read
all of them in one go (when needed).
I think we should support that, because it is relatively easy to generate
that kind of trees for small-scale applications.
However, I think there is also a benefit to handle fan-out directory
structures, too: they scale much nicer.
If the commit name was not found as a filename, it could be searched in
whatever subdirectory whose name is a prefix of said commit name (first
wins).
So I think it would be a sane plan to do the following when a commit note
is requested:
- If not done yet, read in the whole top-level directory of the notes ref.
- If the commit name is not found, find the tree entries whose name is a
prefix of the commit name (we can even use the same hashmap to store
these "incomplete" names, as we use a linear hash, which we fill in
ascending order),
- read the trees one by one, until the commit name is found (or no tree
entry is left), deleting the trees from the hashmap on the go.
How does that sound?
Ciao,
Dscho
--
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
