Johannes Schindelin wrote:
> Or we could use an on-disk hashmap. Oh, wait...
While reading this thread, I sure wondered ... why don't we use the
one on-disk fast access structure we already have: the index?
Sure, one problem is that the index reading code is inherently written
for a single index state. However, all notes consumers I can
currently think of (show, log, anything that displays commit messages)
do not have to access the "real" index.
We'd immediately get lots of tool support for free. Presumably the
real index code has been optimized very well, so it should perform
well. Perhaps there could even be some definition of a NOTES_HEAD
that tracks the current (albeit not checked out, that would be insane)
state.
On a tangent, I'd really like to see a feature that lets us have
several sets of notes (by whatever mechanism). Displaying them as
"Notes from remotes/trast/mailnotes" or similar should be ok. Given
that even before notes are in any release we already have at least two
projects working with mass annotations, it doesn't take much of a
crystal ball to see that the current one-note restriction will be a
limitation.
At a (*very*) cursory glance at read-cache.c, it seems that there is
even support for having several index structures in memory at once,
making this easy. And it looks like reading the cache is more or less
memcpy() if xmmap() is fast (Windows would suffer once again).
Then again I joined this discussion very late so feel free to ignore
my ramblings.
--
Thomas Rast
trast@{inf,student}.ethz.ch
Attachment:
signature.asc
Description: This is a digitally signed message part.
