Junio C Hamano venit, vidit, dixit 08.04.2010 05:53: > Jeff King <peff@xxxxxxxx> writes: > >> I guess an alternate solution would be for me to store them in some >> other ref, and then use --show-notes=email when I do want to see them >> (instead of just --show-notes, as I would do with this patch). But I >> still wonder if log.shownotes is a sensible addition, just for the sake >> of completeness. > > My gut feeling is that people who do have notes in the default namespace > (or the ones in notes.displayRef) do want to see them _all the time_. > Otherwise they'd put such notes in namespaces that are not shown by > default, and view them on demand, no? > > But then there is a bigger question: what kind of notes would you want to > always see as part of "git log" output? My answer to that question for my > personal workflow (both dayjob and here) so far has been "none", and that > is exactly the reason why my "applied from this message" notes live in > notes/am namespace and I have nothing in the default notes namespace. > > If the answer is "none" for everybody, we should disable showing notes in > any command unless the user explicitly asks with either the --show-notes > command line option or the notes.displayRef and perhaps log.shownotes > configuration variables. Personally, I like showing "personal" notes to patches by default. They often end up being the comments after the "---" in patch e-mails. All other notes (such as TR's) I keep in separate name spaces. But I don't mind setting a(nother) config variable for that ;) BTW: I used to keep external notes in refs/remotes/remotename/notes/notestree but since a while ago the notes code insists on refs/notes/. In some sense it is similar to tags, where you need to set up special refspecs if you want to have the remote tags/notes but don't want to mix them (and possibly have them conflict) with your own. But I don't know a good strategy for making this more user friendly. Michael -- 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