threads / discuss / 43905

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

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

## tl;dr

5 messages between Aug 22, 2016 and Aug 23, 2016.

replies: 4people: 3as markdown or json

David Glasser· Aug 22, 2016, 18:42 UTC · lore

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/
Jeff King· Aug 22, 2016, 18:57 UTC · re: David Glasser · lore

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

On Mon, Aug 22, 2016 at 11:42:52AM -0700, David Glasser wrote:
Show 9 quoted lines
> 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
Junio C Hamano· Aug 23, 2016, 17:16 UTC · re: Jeff King · lore

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

Jeff King <peff@peff.net> writes:
Show 8 quoted lines
> 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.

David Glasser· Aug 23, 2016, 17:33 UTC · re: Junio C Hamano · lore

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

On Tue, Aug 23, 2016 at 10:16 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 20 quoted lines
> 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/
Jeff King· Aug 23, 2016, 21:41 UTC · re: Junio C Hamano · lore

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

On Tue, Aug 23, 2016 at 10:16:18AM -0700, Junio C Hamano wrote:
Show 12 quoted lines
> 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...
Show 7 quoted lines
> 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

← back to recent threads