Re: A generalization of git notes from blobs to trees - git metadata?

On Sun, Feb 7, 2010 at 4:02 PM, Jeff King [off-list ref] wrote:

On Sat, Feb 06, 2010 at 06:21:37PM -0800, Junio C Hamano wrote:

quoted

Johan Herland [off-list ref] writes:

quoted

Furthermore, although we currently assume that all note objects are blobs,
someone (who?) has already suggested (as mentioned in the notes TODO list)
that a note object could also be a _tree_ object that can be unpacked/read
to reveal further "sub-notes".

I would advice you not to go there.  How would you even _merge_ such a
thing with other notes attached to the same object?  What determines the
path in that tree object?

Clueless ones can freely make misguided suggestions without thinking
things through and make things unnecessarily complex without real gain.
You do not have to listen to every one of them.

I think I may have been the one to suggest trees or notes at one point.
But let me clarify that this is not exactly what the OP is proposing in
this thread.

My suggestion was that some use cases may have many key/value pairs of
notes for a single sha1. We basically have two options:

 1. store each in a separate notes ref, with each sha1 mapping to
    a blob. The note "name" is the name of the ref.

 2. store notes in a single notes ref, with each sha1 mapping to a
    tree with named sub-notes. The note "name" is the combination of
    ref-name and tree entry name.

So, of course, options (1) and (2) need not be exclusive. Use Option
(1) for different metadata sets and option (2) to partition individual
datasets.

With respect to the idea of storing an arbitrary tree, I agree it is
probably too complex with respect to merging. In addition, it makes
things like "git log --format=%N" confusing. I think you would do better
to simply store a tree sha1 inside the note blob, and callers who were
interested in the tree contents could then dereference it and examine as
they saw fit.  The only caveat is that you need some way of telling git
that the referenced trees are reachable and not to be pruned.

As I see it, the existing use of notes is a special instance of a more
general metadata capability in which the metadata is constrained to be
a single blob. If notes continued to be constrained in this way, there
is no reason to change anything with respect to its current userspace
behaviour. That said, most of the plumbing which enabled notes could
be generalized to enable the arbitrary tree case [ which admittedly, I
have yet to sell successfully !]

In one sense, there is a sense in the merge issue doesn't exist. When
the maintainer publishes a tag no-one expects to have to deal with
downstream conflicting definitions of the tag. Likewise, if the
maintainer were to publish the /man and /html metadata trees (per my
previous example) for a release tag, anyone who received
/refs/metadata/doc would expect to receive the metadata trees as
published by the maintainer. Anyone who didn't wouldn't have to pull
/refs/metadata/doc.

I can see there are use cases where multiple parties might want to
contribute metadata and I do not currently have a good solution to
that problem, but that is not to say there isn't one - surely it is
just a question of applying a little intellect creatively?

jon.