Subject: Re: [PATCH 1/4] gitweb: notes feature

From: Jakub Narebski <[email-masked]>
Date: Sun, 7 Feb 2010 12:08:44 +0100

On Sun, 7 February 2010, Johan Herland wrote:
> On Sunday 07 February 2010, Jakub Narebski wrote:
> > On Sat, 6 Feb 2010, Giuseppe Bilotta wrote:

> > > On the other hand, as mentioned by Junio, this approach is not
> > > future-proof enough for any kind of fan-out schemes.
> > 
> > On the third hand ;-P you propose below a trick to deal with fan-out
> > schemes, assuming that they use 2-character component breaking.
> 
> The current notes code (as it stands in 'pu') use only 2-character component 
> breaking, and I don't see any other fanout mechanism being added anytime 
> soon.

On one hand checking <notes-ref>:403f3b3e..., then <notes-ref>:40/3f3b3e...,
then <notes-ref>:40/3f/3b3e... etc. feels a bit kludgy...

On the other hand it would allow to support notes in gitweb even if git
binary does not have notes support (and yet notes did get somehow into
repository).
 
> > Also, perhaps "git notes show" should acquire --batch / --batch-check
> > options, similar to git-cat-file's options of the same name?
> 
> I'd much rather have support for ^{notes} (or similar) in the rev-parse 
> machinery, so that you could look up deadbeef's notes by passing 
> "deadbeef^{notes}" to 'git cat-file --batch'.

+1.  Good idea!

The only caveat is that if/when we support either of:
* allowing to specify multiple notes namespaces (e.g. multiple --notes-ref
  or --notes option, or PATH-like GIT_NOTES_REF with colon-separated list
  of multiple notes namespaces)
* allowing to have multiple notes per object ('tree' notes)
then <commit-ish>^{notes} would mean multiple objects.  But it is not
much different from supported <commit-ish>^! and <commit-ish>^@ syntax.

[...]
> > > If we have a guarantee that the fan-outs follow a 2/[2/...] scheme,
> > > the open2 approach might still be the best way to go, by just trying
> > > not only namespace:xxxxx...xxx but also namespace:xx/xxxxx etc.
> > > Horrible, but could still be coalesced in a single call. It mgiht also
> > > be optimized to stop at the first successfull hit in a namespace.
> > 
> > Nice trick!  It seems like quite a good idea... but it would absolutely
> > require using 'git cat-file --batch' rather than one git-show per try.
> 
> Still, I'd still much rather use the notes.c code itself for doing this 
> since it should always be the fastest (not to mention future-proof) way of 
> making lookups in the notes tree.

One of Giuseppe goals seems to be to support notes in gitweb even if used
git binary doesn't have support for notes (git-notes command, ^{notes}
extended SHA1 syntax).

-- 
Jakub Narebski
Poland