Thomas Rast <trast@xxxxxxxxxxxxxxx> writes: > On Sunday 21 February 2010 04:47:37 Junio C Hamano wrote: >> >> I like the general direction in which this series is going, but a config >> that does not have any command line counterpart is a design mistake. > > I hate[1] to point out that according to the same criterion, the > *current* notes are a design mistake. Unless you count GIT_NOTES_REF, > in which case in my opinion... With "--no-notes" the caller can explicitly say "please do not show any notes at all" to the log family. "git notes" command itself is about manipluating the notes, and at least with GIT_NOTES_REF the caller can explicitly say what notes tree to work with even when configured value is not appropriate. I also thought there was a work in progress to allow overriding GIT_NOTES_REF from the command line? Having _only_ configuration option is practically no better than having only hardcoded defaults with _no_ way to override it per invocation. What if a user wants to usually see notes from set A (hence it is configured as the value to display-notes-ref configuration) but wants to see notes from a different (maybe overlapping, maybe not) set B during another task? As far as I can see, the _only_ way the current round of RFC lets me do this is by resetting the configuration in the repository. It is not a contrived example. I've been adding the info about the original mailing list message with a patch to commits made with "am" in notes/amlog, and would want to keep test result summary in notes/test. I'd want to see the test notes just before merging topics to integration branches as a final safety check but not all the time. I'd want to see amlog notes when bisect points at a commit in not so near future to be able to dig up the archive with, but not all the time. There needs a per-invocation way to specify which sets of notes to show, and a command line option is the usual way for commands to allow users to do so [*1*]. > I don't really want to go the other way and patch every command that > could conceivably have notes in its output. It is Ok that the series may not be perfect during the RFC period (which the patches were clearly marked as), but I've already said "I like the general direction", wanted to see this series advance from RFC to 'next' material sooner rather than later, and was pointing out what needs to happen for that. [Footnote] *1* We could also use an environment variable, but that is an inferiour alternative to options and configuration variables from the point of view of UI design. Users can export GIT_AUTHOR_NAME, which can serve as an alternative to user.name. This can be overridden per-invocation by "GIT_AUTHOR_NAME=myothername git commit", which can serve as an alternative to --author option. -- 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