Derrick Stolee <derrickstolee@xxxxxxxxxx> writes: >>> + * by the core.notesRef config variable or the >>> + * GIT_NOTES_REFS environment variable. >>> + */ >>> + .ref = "refs/notes/commit", >>> + .exact = 1, >> >> Allowing just "the default" to be replaced by another "custom >> default" is a good start, but we probably want to support more than >> one notes refs, to parallel how "struct display_notes_opt" has >> extra_notes_refs to allow multiple notes refs to decorate objects. > > I imagine that if we allowed multiple notes refs, then we would need > to use a ref prefix to define a namespace. If we relaxed that, then > we could modify this as follows: > > .ref = "refs/notes/", > /* .exact = 0, */ > > (The comment is included just to illustrate the change.) As I do not think it is so bad to decorate a commit with, say, refs/notes/amlog in "git log --notes" (not "git log --notes=amlog") output if such a commit happens to appear, so limiting to the single notes ref that is given by notes.displayRef and ignoring others like the posted patch felt like an over-engineering that may result in even a negative gain. Treating it just like "tags" and "remotes" hierarchy would match intuition better for people, I suspect. Thanks.
