From: Johan Herland <johan@herland.net>
To: Jon Seymour <jon.seymour@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: A generalization of git notes from blobs to trees - git metadata?
Date: Sun, 07 Feb 2010 02:36:12 +0100 [thread overview]
Message-ID: <201002070236.12711.johan@herland.net> (raw)
In-Reply-To: <2cfc40321002060532g4d22dd4dx403bf312708e1424@mail.gmail.com>
On Saturday 06 February 2010, Jon Seymour wrote:
> git notes is a nice innovation - well done to all those involved.
Thanks.
> Has consideration ever been given to generalizing the concept to allow
> note (or more correctly - metadata) trees with arbitrary sha1s?
Not sure what you mean here. The note infrastructure allows _any_ SHA1 (not
necessarily the SHA1 of an existing Git object) to be bound to a note
object.
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". Hence, in addition to having multiple notes
refs (e.g. refs/notes/commits:deadbeef, refs/notes/bugs:deadbeef, etc.) to
categorize notes, you could also classify notes _after_ having traversed the
notes tree (e.g. refs/notes/bugs:deadbeef/fixes,
refs/notes/bugs:deadbeef/causes). Note that support for this has not yet
been written, and AFAIK it is also uncertain how such a change would affect
the different use cases for notes (e.g. how to display them in 'git log')
> For example, suppose you had reason to cache the distribution that
> resulted from the build of a particular commit, then it'd be nice to
> be able to do this using a notes like mechanism.
>
> git metadata import foo-1.1.0 dist ~/foo/dist
>
> would create a git tree from the contents of ~/foo/dist and then bind
> it to meta item called dist associated with the sha1 corresponding to
> foo-1.1.0
You can do this already today by simply using 'git tag':
# Prepare an index with the contents of ~/foo/dist
git tag foo-1.1.0-dist $(git write-tree)
I don't see why you'd need to add a new metadata command.
> To retrieve the contents of the previous build, you'd do something like
>
> get metadata export foo-1.1.0 dist /tmp/foo-1.1.0
>
> This would find the metadata tree associated with foo-1.1.0, extract
> the dist subtree from that tree and write it to disk at /tmp/foo-1.1.0
Or, if you use a tag instead:
git --work-tree=/tmp/foo-1.1.0 checkout foo-1.1.0-dist
> I've used build outputs as an example here, but really it needn't be
> limited to that. I can see this facility would be useful for any kind
> of annotation or derived result that is more complex than a single
> text blob. Metadata trees in combination with a name spacing
> technique, could be used to store arbitrary metadata created by an
> arbitrary set of tools to arbitrary SHA1 objects.
I still don't see why this provides anything that isn't already supported by
either using 'git tag', or by implementing support for notes-as-trees in the
notes feature.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
next prev parent reply other threads:[~2010-02-07 1:46 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-06 13:32 A generalization of git notes from blobs to trees - git metadata? Jon Seymour
2010-02-07 1:36 ` Johan Herland [this message]
2010-02-07 2:21 ` Junio C Hamano
2010-02-07 5:02 ` Jeff King
2010-02-07 5:36 ` Jon Seymour
2010-02-07 9:15 ` Jakub Narebski
2010-02-07 9:41 ` Jon Seymour
2010-02-07 10:15 ` Jon Seymour
2010-02-07 19:33 ` Jeff King
2010-02-07 20:25 ` Junio C Hamano
2010-02-08 2:03 ` Steven E. Harris
2010-02-10 5:09 ` Jeff King
2010-02-10 5:23 ` Junio C Hamano
2010-02-10 5:29 ` Jeff King
2010-02-07 18:48 ` Junio C Hamano
2010-02-07 19:18 ` Jeff King
2010-02-07 22:46 ` Johan Herland
2010-02-07 3:27 ` Jon Seymour
2010-02-07 4:32 ` Jon Seymour
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201002070236.12711.johan@herland.net \
--to=johan@herland.net \
--cc=git@vger.kernel.org \
--cc=jon.seymour@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).