Johannes Schindelin [off-list ref] writes:
With the provided script, edit-commit-annotations, you can add
after-the-fact annotations to commits, which will be shown by
the log if the config variable core.showannotations is set.
The annotations are tracked in a new ref, refs/annotations/commits,
in the same fan-out style as .git/objects/??/*, only that they only
exist in the object database now.
Signed-off-by: Johannes Schindelin <redacted>
---
I have the hunch that this will be relatively fast and scalable,
since the tree objects are sorted by name (the name being the
object name of the to-be-annotated commit).
The entries of tree are sorted but not necessarily of uniform
length so you end up needing linear search anyway. The fan-out
would help with the current tree objects.
It will hurt _if_ we introduce a new tree object format that
would give you a quick random-access at an entry, but it is
premature to worry about that now.
Hi,
On Sun, 10 Jun 2007, Junio C Hamano wrote:
Johannes Schindelin [off-list ref] writes:
quoted
With the provided script, edit-commit-annotations, you can add
after-the-fact annotations to commits, which will be shown by
the log if the config variable core.showannotations is set.
The annotations are tracked in a new ref, refs/annotations/commits,
in the same fan-out style as .git/objects/??/*, only that they only
exist in the object database now.
Signed-off-by: Johannes Schindelin <redacted>
---
I have the hunch that this will be relatively fast and scalable,
since the tree objects are sorted by name (the name being the
object name of the to-be-annotated commit).
The entries of tree are sorted but not necessarily of uniform
length so you end up needing linear search anyway. The fan-out
would help with the current tree objects.
I do not understand... the entries of a tree object are sorted
alphabetically, right? Including the convention that if one is a prefix of
another, it is "smaller".
While I think that the length would not be any problem, the entries' names
of refs/annotations/commit^{tree} are _all_ of length two, and point to
other tree objects. _Those_ tree objects contain _only_ entries whose
names contain exactly 38 characters.
It will hurt _if_ we introduce a new tree object format that would give
you a quick random-access at an entry, but it is premature to worry
about that now.
I do not see that. Care to enlighten me?
Ciao,
Dscho