On Tue, Aug 23, 2016 at 10:16:18AM -0700, Junio C Hamano wrote:
> Jeff King <peff@xxxxxxxx> writes:
>
> > That seems like the most sensible place, as that is where we should
> > cover the order of reading and precedence. Perhaps FILES should be
> > renamed to SOURCES or something (though I do not recall if we are
> > restricted to "usual" manpage section names or not).
> >
> > Arguably this is not about git-config the program at all, but the
> > general concept of "configuration for git", because the precedence rules
> > apply equally to all of the git programs that read config.
>
> True, but that argument leads us to say git(1) is the best place ;-)
Sort of. I agree it is a good place to mention the precedence, but...
> If the user wants to know "how does the configuration values get
> read?", and wishes not having to go around fishing for the
> information in multiple places (and I think that is a reasonable
> thing to wish for), I think adding it to the FILES section of
> git-config(1) is a better option than inventing a separate
> gitconfig(7), which would still require the user to consult two
> places.
The flip side of "fishing for the information in multiple places" is "I
know it is somewhere in git-config(1), but I have to wade through a
bunch of cruft about git-config command-line options to find it".
So I'd argue that the concept of config (overview, precedence, file
syntax, list of options) could be separate from both git-config(1) and
from git(1), and that both of those places could point to it. That
introduces a level of indirection which is annoying the first time ("I
am reading git-config(1), but now I have to jump to another manpage")
but helpful the other times ("I know I want config concepts, not the
config tool; I can immediately jump to the right place").
Anyway. Just my two cents on the matter. I think we can improve David's
complaint without anything so drastic.
-Peff
--
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