what's the difference between `[github]` and `[github "user"]` in a gitconfig file?

Question

I have the following two blocks in my gitconfig with real info in place of <placeholders>:

[github]
  user = <name>
  token = <token>
  email = <email address>
[github "user"]
  user = <name>
  token = <token>
  email = <email address>

Both contain the same 3 values I imagine this is unnecessary duplication, but what's the difference and which should I remove? It's not causing any problems as is.

Furthermore, I also have this block:

[user]
  name = <name>
  email = <email address>

Again, same name and email address.

Update: Running git config --list displayed values for

github.user
github.token
github.email

as well as

github.user.user
github.user.token
github.user.email

which just looked so wrong to me, I removed the whole [github "user"] block from my file. Nothing seems broken yet.

Answer 1

As far as I know, that syntax means you have a github section and a github "user" subsection (see under Syntax). This means you can access github and you can also access github.user as you have noticed with --list. That way you can store different values. Since your values are the same you should be able to remove the [github "user"] without breaking anything, as you saw.

Answer 2

Note: beware of git config subsections: Recent update to "git config" broke updating variable in a subsection, which has been corrected with Git 2.19 (Q3 2018).

This illustrates the difference between a section and subsection.

See commit bff7df7, commit 2d84f13 (08 Aug 2018), and commit 999d902 (01 Aug 2018) by Stefan Beller (stefanbeller).
^{(Merged by Junio C Hamano -- gitster -- in commit 2a2c18f, 20 Aug 2018)}

config: fix case sensitive subsection names on writing

A user reported a submodule issue regarding a section mix-up, but it could be boiled down to the following test case:

$ git init test  && cd test
$ git config foo."Bar".key test
$ git config foo."bar".key test
$ tail -n 3 .git/config
[foo "Bar"]
      key = test
      key = test

Sub sections are case sensitive and we have a test for correctly reading them.
However we do not have a test for writing out config correctly with case sensitive subsection names, which is why this went unnoticed in 6ae996f (git_config_set: make use of the config parser's event stream, 2018-04-09, Git 2.18)

Unfortunately we have to make a distinction between old style configuration that looks like:

[foo.Bar]
      key = test

and the new quoted style as seen above.

The old style is documented as case-agnostic, hence we need to keep 'strncasecmp'; although the resulting setting for the old style config differs from the configuration.

---

Make sure to use Git 2.19 (as seen above), or at the very least Git 2.13 or more.

What is not documented is that git -c used to lowercase the variable name:

vonc@bvonc MINGW64 ~
$ git version
git version 2.12.0.windows.1

vonc@bvonc MINGW64 ~
$ git -c VAR=c config -l|grep var
var=c

That can be an issue on OS where the variable case matters (see also the url case below)

This is fixed in Git 2.13 (Q2 2017), and that provides another illustration of the difference between a section and subsection.

See commit 1274a15 and commit ee98df3 (23 Feb 2017) by Junio C Hamano (gitster).
^{(Merged by Junio C Hamano -- gitster -- in commit 2f54451, 10 Mar 2017)}

config: use git_config_parse_key() in git_config_parse_parameter()

The parsing of one-shot assignments of configuration variables that come from the command line historically was quite loose and allowed anything to pass.

It also downcased everything in the variable name, even a three-level <section>.<subsection>.<variable> name in which the part must be treated in a case sensitive manner.

An example of three-level <section>.<subsection>.<variable> name where the case DOES matter, no matter the OS is when setting an url:

vonc@bvonc MINGW64 ~
$ git -c url."https://myserver/GitLab".insteadOf=git@myserver.org/GitLab config -l|grep -i Gitlab
url.https://myserver.org/gitlab.insteadof=git@myserver.org/GitLab

If your private Git repo server URL is not fully lowercase... that command would not work.
While the scheme of an url might be case insensitive, as well as the domain, the rest of the url (here the /GitLab part) can be case sensitive.