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

From: Jeff King <peff@peff.net>
Date: Sep 27, 2011, 21:58 UTC
Message-ID: <20110927215843.GE5176@sigill.intra.peff.net>
In-Reply-To: <4E7DEC4A.3050900@drmicha.warpmail.net>

On Sat, Sep 24, 2011 at 04:42:18PM +0200, Michael J Gruber wrote:

Show 13 quoted lines

> > 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

Sure, but what about:

  git notes list

which is just filled with meaningless nonsense.

Show 12 quoted lines

> > 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.

Hmm. So your mapping of $ref to $desc is:

  sha1($ref) -> sha1(blob($desc))

>From what you wrote there, I think maybe you think I meant to store:

  sha1(blob($ref)) -> sha1(blob($desc))

But what I meant was actually:

  $ref -> sha1(blob($desc))

I.e., not to use "notes" at all, but rather a tree that mirrors the refs/ hierarchy in its names.

Show 7 quoted lines

> > 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?

It's one way. I assume that if we store things in a reasonable, readable state, then people like that because they can hack on the data structure using more flexible tools.

Show 5 quoted lines

> 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

If they are local by nature, is it worth putting them into a notes tree at all? That provides versioning and backup. But I wonder if it is worth the hassle, when one could just put them in the config.

-Peff