Re: [PATCH 0/6] A handful of "branch description" patches

[Michael J Gruber <git@drmicha.warpmail.net>]

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