Re: notes TODOs (was: Re: [PATCH 1/4] gitweb: notes feature)

[Giuseppe Bilotta <giuseppe.bilotta@gmail.com>]

On Fri, Feb 5, 2010 at 4:27 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Fri, 5 Feb 2010, Johan Herland wrote:
>> On Friday 05 February 2010, Giuseppe Bilotta wrote:
>
>> > If I may be allowed to add a suggestion to put in the list, I would
>> > like to see notes attachable to named refs (branch heads in
>> > particular). From a cursory reading of your patches currently in pu
>> > it would seem that you explicitly prohibit this case currently.
>> > However, this has many possible uses, ranging from longer branch
>> > descriptions to tracking information to improve survival in case of
>> > remote rebases.
>>
>> Nope. There is no explicit prohibition on anything. On a fundamental
>> level, Git-notes simply maps a given SHA1 (the annotated object) to
>> another SHA1 (the object holding the annotation itself). In principle
>> you can annotate _any_ SHA1, it doesn't even have to exist as a git
>> object!
>
> I guess that it isn't currently possible to map _path_ (here: fully
> qualified name of ref, i.e. "refs/heads/master" in example) to SHA1
> rather than SHA1 to SHA1, as fan-outs assumes mapping of SHA1 (to
> object).
>
>>
>> In fact, something like the following abomination should solve
>> your "problem" quite easily:
>>
>>   git notes add $(echo "refs/heads/master" | git hash-object --stdin)
>>
>> (...washing my hands...)
>
> This actually annotates (existing or not) _blob_ object with
> "refs/heads/master" as contents (git-hash-object defaults to -t blob).

Well, it still might work assuming the git tools know that they have
to look for these notes too when looking notes up. If we tolerate the
funky failure in the unlikely case of a file whose content matches a
ref name, it could be used to implement the feature without having to
remove the assumption that notes pretargets are SHA1. I do believe
that removing that assumption would be a smoother way to go, although
I have no idea how hard it would be to implement.

>> > And one last comment: how do notes behave wrt to cloning and remote
>> > handling? Am I correct in my understanding that notes are
>> > (presently) local only? Would it make sense to have them cloned to
>> > something like the refs/notes/remotes/* namespace?
>>
>> They are no more local than any other ref, except that they are
>> outside the refspecs that are "usually" pushed/fetched (refs/heads/
>> and refs/tags/).
>>
>>       git push <remote> refs/notes/<foo>
>>       git fetch <remote> refs/notes/<foo>[:refs/notes/<foo>]
>>       etc.
>>
>> should all work as expected.
>
> It would be nice, but I guess not possible, to have notes autofollowed
> on fetch, like tags are autofollowed...

Tags have the idiosincracy of living in the same namespace regardless
of where they come from, and I believe there a little too high a risk
of conflicts to do this with notes too. It might make sense to add a
default fetch of +refs/notes/*:refs/notes/remotes/<remote>/*, but the
real question is what would pushing do, in case of conflicting notes.

-- 
Giuseppe "Oblomov" Bilotta