Jeff King venit, vidit, dixit 23.09.2011 22:18:
> On Fri, Sep 23, 2011 at 10:56:47AM +0200, Michael J Gruber wrote:
>
>> mjg/vob/refrev-pretend [mjg/vob/virtual-objects: ahead 1]
>> Pseudo revs for refnames
>>
>> An alternative implementation using pretend_sha1...
>> Currently unused.
>>
>> mjg/vob/virtual-objects [origin/next: ahead 2, behind 10]
>> Virtual refname objects
>>
>> For each existing refname, introduce virtual objects corresponding to a blob
>> with the refname as the content. "virtual" refers to the fact that these
>> objects are not written out but exist for all other purposes, such as
>> attaching notes and keeping them from being pruned.
>
> Eww. :)
>
> This seems like a clever solution to making git-notes store a ref as a
> key instead of an arbitrary sha1. But I wonder if the end result is
> really waht the user wants. The resulting notes tree is good for doing
> lookups, but the entries are completely obfuscated. So I can't easily do
> something like "list all of the refs which have descriptions". I can
> only list the _hashes_ of the refs which have descriptions. And if I am
> lucky, I can hash the refs I have and correlate them. But unknown ones
> will simply be a mystery.
[mjg@localhost git]$ git rev-parse ref:mjg/vob/virtual-objects
3f8aa9bb80fe241306aafd3d76af50739ba88268
[mjg@localhost git]$ git show 3f8aa9bb80fe241306aafd3d76af50739ba88268
refs/heads/mjg/vob/virtual-objects
:)
The only problem is with notes for non-existing refs. [You only have to
invoke the inverse mapping to sha1, of course... Uhm.]
> Wouldn't it be much more friendly to have a separate tree of refnames
> that stores:
>
> refs/heads/foo -> (some blob with the "foo" description)
> refs/heads/bar -> (some blob with the "bar" description)
Given the above, I don't think it's more friendly.
In fact, in my first attempt, I wrote out the blobs, and referenced them
just like above from a different subtree within the notes tree, in order
to keep them from being pruned. So the virtual approach is pretty
equivalent, though leaner.
> Yeah, you have to build another git-notes-like interface around it. But
> the data structure is pleasant and flexible. You could even "git
> checkout" the whole tree and edit the notes with your editor, without
> having to deal with some obfuscated name.
Well, "git branch --edit-description" and such should be the way to edit
them, shouldn't it?
I really think the only issue is remote refnames. As Junio points out,
they are local by nature. OTOH, you typically use a non-renaming refspec
which puts them under refs/remotes/foo/bar with "bar" being the same
name as the local one on the remote, foo something you have chosen. So,
teaching the code that the note for
refs/remotes/foo/bar
is in the notes tree
refs/remotes/foo/notes/commits (or .../refames, or whatever we do with
the namespaces)
as a note attached to sha1("refs/bar")
is really a non-issue. It's not done yet, in part because of the
possible namespace restructuring.
Michael
--
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