{"thread":{"id":"44569","subject":"gitconfig includes","startedAt":"2016-11-29T19:40:15Z","lastAt":"2016-11-30T19:45:08Z","messageCount":8,"participants":["Eli Barzilay","Junio C Hamano","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"306564","messageId":"CALO-gutW80d6RLdXAtYA2m2GWOchAjNNPy3YCsr31_fCss512g@mail.gmail.com","threadId":"44569","inReplyTo":null,"subject":"gitconfig includes","fromName":"Eli Barzilay","fromEmail":"eli@barzilay.org","sentAt":"2016-11-29T19:40:09Z","receivedAt":"2016-11-29T19:40:15Z","isPatch":false,"sender":{"key":"eli@barzilay.org","avatar":"https://avatars.githubusercontent.com/u/185905?v=4"},"body":"I just noticed something weird: if I have this in my ~/.gitconfig:\n\n [x]\n x = global\n [include]\n path = .gitconfig.more\n\nand .gitconfig.more has\n\n [x]\n x = more\n\nthen I get:\n\n1. git config x.x => more\n2. git config --global x.x => global\n3. git config --global --includes x.x => more\n\nThe first works as I expected. The second surprised me, since I took\n\"--global\" to mean \"the global file and stuff it includes\" (that's my\nunderstanding of the description of `include`). The third is fine, but\nit made me even more surprised at the second, especially since the man\nblurb on --includes says \"Defaults to on.\"...\n\nSo this is at least a documentation issue, though I hope that #2 is a\nbug and that it *should* return \"more\"...?\n\n-- \n ((x=>x(x))(x=>x(x))) Eli Barzilay:\n http://barzilay.org/ Maze is Life!\n"},{"id":"306565","messageId":"xmqq7f7mf4rs.fsf@gitster.mtv.corp.google.com","threadId":"44569","inReplyTo":"CALO-gutW80d6RLdXAtYA2m2GWOchAjNNPy3YCsr31_fCss512g@mail.gmail.com","subject":"Re: gitconfig includes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-11-29T19:46:31Z","receivedAt":"2016-11-29T19:46:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eli Barzilay writes:\n\n> So this is at least a documentation issue,...\n\nThis already is documented, and I think it is clear enough.\n\n --[no-]includes\n Respect include.* directives in config files when\n looking up values. Defaults to off when a\n specific file is given (e.g., using --file,\n --global, etc) and on when searching all config\n files.\n\n"},{"id":"306566","messageId":"CALO-gutJbM=LA3q8vdmbQJLoeCFAJWfPHFo8f1vz-5KJHVxJ6g@mail.gmail.com","threadId":"44569","inReplyTo":"xmqq7f7mf4rs.fsf@gitster.mtv.corp.google.com","subject":"Re: gitconfig includes","fromName":"Eli Barzilay","fromEmail":"eli@barzilay.org","sentAt":"2016-11-29T19:53:08Z","receivedAt":"2016-11-29T19:54:08Z","isPatch":false,"sender":{"key":"eli@barzilay.org","avatar":"https://avatars.githubusercontent.com/u/185905?v=4"},"body":"On Tue, Nov 29, 2016 at 2:46 PM, Junio C Hamano wrote:\n> Eli Barzilay writes:\n>\n>> So this is at least a documentation issue,...\n>\n> This already is documented, and I think it is clear enough.\n>\n> --[no-]includes\n> Respect include.* directives in config files when\n> looking up values. Defaults to off when a specific\n> file is given (e.g., using --file, --global, etc)\n> and on when searching all config files.\n\nYeah, that's clear, sorry for not checking the latest.\n\n[I'd expect/wish it to be on by default though... Any reason for the\ndefault being off in these cases?]\n\n-- \n ((x=>x(x))(x=>x(x))) Eli Barzilay:\n http://barzilay.org/ Maze is Life!\n"},{"id":"306576","messageId":"20161129214604.c5xcw3d2a5ydpx42@sigill.intra.peff.net","threadId":"44569","inReplyTo":"CALO-gutJbM=LA3q8vdmbQJLoeCFAJWfPHFo8f1vz-5KJHVxJ6g@mail.gmail.com","subject":"Re: gitconfig includes","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-11-29T21:46:04Z","receivedAt":"2016-11-29T21:47:14Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Nov 29, 2016 at 02:53:08PM -0500, Eli Barzilay wrote:\n\n> > This already is documented, and I think it is clear enough.\n> >\n> > --[no-]includes\n> > Respect include.* directives in config files when\n> > looking up values. Defaults to off when a specific\n> > file is given (e.g., using --file, --global, etc)\n> > and on when searching all config files.\n> \n> Yeah, that's clear, sorry for not checking the latest.\n> \n> [I'd expect/wish it to be on by default though... Any reason for the\n> default being off in these cases?]\n\nIt definitely needs to default to off for \"-f\", as we would not want\nsurprises when accessing files like \".gitmodules\" that come from\nuntrusted sources.\n\nI think it's arguable whether \"--global\" should behave the same. It\nmakes the rule simple: \"if you specify a single file, includes default\nto off\". But I don't think there would be any particular harm. The\nexisting default was mostly chosen for simplicity and least-surprise\nwith respect to backwards compatibility.\n\nThere's a little more discussion in 9b25a0b52 (config: add include\ndirective, 2012-02-06).\n\n-Peff\n"},{"id":"306577","messageId":"xmqqeg1udkg4.fsf@gitster.mtv.corp.google.com","threadId":"44569","inReplyTo":"20161129214604.c5xcw3d2a5ydpx42@sigill.intra.peff.net","subject":"Re: gitconfig includes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-11-29T21:50:51Z","receivedAt":"2016-11-29T21:53:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I think it's arguable whether \"--global\" should behave the same.\n\nI know you know this and I am writing this message for others.\n\nI admit that I wondered if \"a single file\" ought to cover these\nshort-hand notations like --global and --local while re-reading the\nlog message of 9b25a0b52 (config: add include directive,\n2012-02-06). In other words, I agree that it used to be arguable\nbefore we released v1.7.10.\n\nIt no longer is arguable simply due to backward compatibilty. The\nship has long sailed.\n\n\n"},{"id":"306595","messageId":"CALO-gusHzTaLg=7X=KqYB==Yz_6yH6qkh8GDK54Lacu5ofD2pw@mail.gmail.com","threadId":"44569","inReplyTo":"xmqqeg1udkg4.fsf@gitster.mtv.corp.google.com","subject":"Re: gitconfig includes","fromName":"Eli Barzilay","fromEmail":"eli@barzilay.org","sentAt":"2016-11-30T18:54:35Z","receivedAt":"2016-11-30T18:54:46Z","isPatch":false,"sender":{"key":"eli@barzilay.org","avatar":"https://avatars.githubusercontent.com/u/185905?v=4"},"body":"On Tue, Nov 29, 2016 at 4:50 PM, Junio C Hamano wrote:\n> Jeff King writes:\n>\n>> I think it's arguable whether \"--global\" should behave the same.\n>\n> I know you know this and I am writing this message for others.\n>\n> I admit that I wondered if \"a single file\" ought to cover these\n> short-hand notations like --global and --local while re-reading the\n> log message of 9b25a0b52 (config: add include directive,\n> 2012-02-06). In other words, I agree that it used to be arguable\n> before we released v1.7.10.\n>\n> It no longer is arguable simply due to backward compatibilty. The\n> ship has long sailed.\n\nI don't have any strong opinion, but FWIW, the use case I have for this\nis as follows: I sync my ~/.gitconfig between my own machine and a work\nmachine. On the work machine though, I like people to have work emails,\nand I wrote some scripts that verify that. For my case, I added an\ninclude of a ~/.gitconfig.more which is not synced, and has values that\noverride the ones in ~/.gitconfig. Since I'm the one who also wrote\nthat script, I just added an \"--includes\" to the check so it won't barf\non my setup, but had it not been my script I'd be stuck.\n\nThis is all a \"FWIW\" -- in case anyone thinks about use cases for a\npossible (future) change of the default.\n\n-- \n ((x=>x(x))(x=>x(x))) Eli Barzilay:\n http://barzilay.org/ Maze is Life!\n"},{"id":"306596","messageId":"20161130190653.kk5pboas54yen2it@sigill.intra.peff.net","threadId":"44569","inReplyTo":"CALO-gusHzTaLg=7X=KqYB==Yz_6yH6qkh8GDK54Lacu5ofD2pw@mail.gmail.com","subject":"Re: gitconfig includes","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-11-30T19:06:53Z","receivedAt":"2016-11-30T19:13:48Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Nov 30, 2016 at 01:54:35PM -0500, Eli Barzilay wrote:\n\n> I don't have any strong opinion, but FWIW, the use case I have for this\n> is as follows: I sync my ~/.gitconfig between my own machine and a work\n> machine. On the work machine though, I like people to have work emails,\n> and I wrote some scripts that verify that. For my case, I added an\n> include of a ~/.gitconfig.more which is not synced, and has values that\n> override the ones in ~/.gitconfig. Since I'm the one who also wrote\n> that script, I just added an \"--includes\" to the check so it won't barf\n> on my setup, but had it not been my script I'd be stuck.\n\nI'm not sure what your script does exactly, but in general I think the\nright thing for most scripts is _not_ to use a specific-file option like\n--global.\n\nIf the script is looking up a config value on behalf of a user, it\nprobably makes sense for it to use the normal config lookup procedure\n(system, global, repo, command-line), which also enables includes by\ndefault. That would make it consistent with internal git config lookups\n(e.g., user.name probably only ever appears in global config, but you\n_can_ override it at the repo level if you want to).\n\nI know that's mostly orthogonal to what we're discussing, but I'd feel\nmore convinced that enabling \"--includes\" with \"--global\" is useful if I\nthought that \"--global\" was useful in the first place outside of a few\nnarrow debugging cases.\n\n-Peff\n"},{"id":"306597","messageId":"CALO-guvsVgHp41ubvuKzmH3c4rE+3io3GaYie3=Q-4jdG91CDQ@mail.gmail.com","threadId":"44569","inReplyTo":"20161130190653.kk5pboas54yen2it@sigill.intra.peff.net","subject":"Re: gitconfig includes","fromName":"Eli Barzilay","fromEmail":"eli@barzilay.org","sentAt":"2016-11-30T19:42:58Z","receivedAt":"2016-11-30T19:45:08Z","isPatch":false,"sender":{"key":"eli@barzilay.org","avatar":"https://avatars.githubusercontent.com/u/185905?v=4"},"body":"On Wed, Nov 30, 2016 at 2:06 PM, Jeff King wrote:\n>\n> I'm not sure what your script does exactly, but in general I think the\n> right thing for most scripts is _not_ to use a specific-file option\n> like --global.\n>\n> If the script is looking up a config value on behalf of a user, it\n> probably makes sense for it to use the normal config lookup procedure\n> (system, global, repo, command-line), which also enables includes by\n> default. That would make it consistent with internal git config\n> lookups (e.g., user.name probably only ever appears in global config,\n> but you _can_ override it at the repo level if you want to).\n\nThis is intended for git newbies (and big company => infinite supply of\nthem), and also allows them to conveniently nuke the repo and start from\na fresh copy, so it makes sense to make the script inspect/tweak the\nglobal settings. If knowing git \"well enough\" was an assumed\nrequirement, I'd definitely do the normal thing.\n\n\n> I know that's mostly orthogonal to what we're discussing, but I'd feel\n> more convinced that enabling \"--includes\" with \"--global\" is useful if\n> I thought that \"--global\" was useful in the first place outside of a\n> few narrow debugging cases.\n\nOk. Perhaps I overestimated the utility of --global anyway, given the\nabove...\n\n-- \n ((x=>x(x))(x=>x(x))) Eli Barzilay:\n http://barzilay.org/ Maze is Life!\n"}]}