> > 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) > > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html