Re: Commit notes workflow

quoted

Do we really want to "git notes" to ignore everything not in  refs/notes/
? I can think of 2 possibilities out of this situation:

* remove that limitation
* decide on a naming convention for remote notes, and teach  "git notes"
not to ignore it

The naming convention I have proposed (in the discussion for 
[1]) is 

refs/notes/*:refs/remotes/$remote/notes/*

(but it obviously depends on reorganizing the entire remote refs  hierarchy)

quoted

A (minor) problem with the second possibility is that this naming
convention could evolve, eg. if we end up with something like was
proposed in [1] for 1.8.0. Is there any real drawback with  the first
suggestion ?

[1] http://marc.info/?l=git&m=129661334011986&w=4

My gut feeling is to keep some sort of limit notes refs, and  if/when we get 
around to implementing my proposal in [1] (or some variation  thereof), we 
will of course extend the limit to put  "refs/remotes/$remote/notes/*" (or 
whatever is decided) in the same category as "refs/notes/*".

In the meantime, I'm unsure if it's a good idea to remove the  limitation 
altogether (allowing notes refs everywhere), since re- introducing a limit at 
a later point will then be MUCH harder...

So we could introduce something like refs/remote-notes/<remote>/* today to
start working, and eventually phase it out when refs/remotes/ gets restructured.

Then the next point will be how best to provide git-pull-like support for notes refs.
We have a number of alternatives, like:

* having "git pull" run "git notes merge" on all notes refs with a tracking-branch set to
   the repo from which we pull
* do the same for a configured set of notes refs only
* only have "git pull" and "git status" notify about notes refs being not uptodate, and
   add an explicit "git notes pull" command of some sort (maybe just "git notes merge"
   without an argument, which would be consistent with latest "git merge")
* surely others