Junio C Hamano wrote: > Jonathan Nieder <jrnieder@xxxxxxxxx> writes: >> How about >> >> refs/notes/* refs/notes/$remote/* >> >> ? > > I was actually thinking more along the lines of "not keeping track of > remote state at all". We don't do that for tags either. What would be the behavior when a remote and local notes ref have the same name? Tags are supposed to be universal and never change, so that doesn't come up. With branches and notes trees, one can impose a requirement that the remote and local refs never have the same name (the "no separate remotes" layout) but I think that runs into problems from both ends: When the remote and local notes are written by the same person, it seems like busy work to ask that person to give different names for the same branch at different installations. In a distributed world where many developers might not even know about each other's repositories, name conflicts on development branches would seem to be inevitable. home> ... hack hack hack ... home> git notes add some-commit; # hmm, noticed something home> ... hack hack hack ... Time to go to work... work> ... hack hack hack ... work> git notes add another-commit work> ... hack hack hack ... work> git fetch home; # grabbing notes from home. work> git notes merge home/commits work> git push; # publish. Still, as long as the default can be overridden (even if only on a per-remote basis), I wouldn't mind. Maybe this way of using notes would be unusual and the no-separate-remotes layout supports some other use case better. -- 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