git-config(1) should mention `git -c`

git-config(1) should mention `git -c`

[David Glasser]

In addition to describing the `git config` command, git-config(1) also
appears to be where the algorithm for determining the active
configuration values is documented, in the FILES and ENVIRONMENT
sections.  (There is minimal documentation of these files and
environment variables in git(1).)

However, `git -c name=value` is not documented in this manpage. So to
understand the full set of ways to affect the configuration of a git
command, you need to know to read both git(1) and git-config(1).

I'd like to add a reference to `git -c` to git-config(1). I would
happily send a patch but I'm not sure of the best place to put it —
maybe in the FILES section?

--dave

-- 
glasser@davidglasser.net | langtonlabs.org | flickr.com/photos/glasser/

Re: git-config(1) should mention `git -c`

[Jeff King]

On Mon, Aug 22, 2016 at 11:42:52AM -0700, David Glasser wrote:

> In addition to describing the `git config` command, git-config(1) also
> appears to be where the algorithm for determining the active
> configuration values is documented, in the FILES and ENVIRONMENT
> sections.  (There is minimal documentation of these files and
> environment variables in git(1).)
> 
> However, `git -c name=value` is not documented in this manpage. So to
> understand the full set of ways to affect the configuration of a git
> command, you need to know to read both git(1) and git-config(1).

Yeah, I agree it is probably worth mentioning in git-config(1).

> I'd like to add a reference to `git -c` to git-config(1). I would
> happily send a patch but I'm not sure of the best place to put it —
> maybe in the FILES section?

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. So it _could_
be pulled out into its own gitconfig(7) page. That's a lot more work,
though, and I don't blame you if you want to start with a more minor
update.

(I also think that having both git-config(1) and gitconfig(7) may be
confusing; "git help revisions" knows to find gitrevisions(7), but "git
help config" would always end up in git-config(1), I think).

-Peff

Re: git-config(1) should mention `git -c`

[Junio C Hamano]

Jeff King <peff@peff.net> 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 ;-)

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.

Re: git-config(1) should mention `git -c`

[David Glasser]

On Tue, Aug 23, 2016 at 10:16 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Jeff King <peff@peff.net> 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 ;-)
>
> 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.

Great, I sent a patch in a new thread. I hope I formatted it
correctly; haven't sent a patch via email in a while.



-- 
glasser@davidglasser.net | langtonlabs.org | flickr.com/photos/glasser/

Re: git-config(1) should mention `git -c`

[Jeff King]

On Tue, Aug 23, 2016 at 10:16:18AM -0700, Junio C Hamano wrote:

> Jeff King <peff@peff.net> 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