Re: [RFC PATCH v3 00/12] several notes refs, post-rewrite, notes rewriting

[Junio C Hamano <gitster@pobox.com>]

Thomas Rast <trast@student.ethz.ch> 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.