{"thread":{"id":"45924","subject":"Possible bug in includeIf / conditional includes","startedAt":"2017-05-10T17:00:47Z","lastAt":"2017-05-12T18:45:07Z","messageCount":22,"participants":["raphael.stolt@gmail.com","Sebastian Schuberth","Ævar Arnfjörð Bjarmason","Raphael Stolt","Jeff King","Junio C Hamano","Ramsay Jones"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"319279","messageId":"C1ACB28C-F1B4-42A1-8135-797DEFD9F03C@gmail.com","threadId":"45924","inReplyTo":null,"subject":"Possible bug in includeIf / conditional includes","fromName":"","fromEmail":"raphael.stolt@gmail.com","sentAt":"2017-05-10T17:00:39Z","receivedAt":"2017-05-10T17:00:47Z","isPatch":false,"sender":{"key":"raphael.stolt@gmail.com","avatar":"https://gravatar.com/avatar/132faf5713fa951f4263fad02858a62e55c5d832ad775b33e49ba0cda2f2a028?d=mp&s=160"},"body":"Hi there,\n\nI might have stumbled over a bug in includeIf / conditional includes or maybe it's just as intended.\n\nCurrent configuration which finds the conditional configuration.\n\n~/.gitconfig\n[includeIf \"gitdir:~/Work/git-repos/oss/\"]\n path = ~/Work/git-repos/oss/.oss-gitconfig\n\nExpected configuration which doesn't find the conditional configuration:\n\n~/.gitconfig\n[includeIf \"gitdir:~/Work/git-repos/oss/\"]\n path = .oss-gitconfig\n\nBest regards,\n\nRaphael Stolt"},{"id":"319289","messageId":"b80c68fa-fe1e-3cf8-3c7e-527a4d941108@gmail.com","threadId":"45924","inReplyTo":"C1ACB28C-F1B4-42A1-8135-797DEFD9F03C@gmail.com","subject":"Re: Possible bug in includeIf / conditional includes","fromName":"Sebastian Schuberth","fromEmail":"sschuberth@gmail.com","sentAt":"2017-05-10T18:58:18Z","receivedAt":"2017-05-10T19:00:23Z","isPatch":false,"sender":{"key":"sschuberth@gmail.com","avatar":"https://avatars.githubusercontent.com/u/349154?v=4"},"body":"On 2017-05-10 19:00, raphael.stolt@gmail.com wrote:\n\n> Current configuration which finds the conditional configuration.\n> \n> ~/.gitconfig\n> [includeIf \"gitdir:~/Work/git-repos/oss/\"]\n> path = ~/Work/git-repos/oss/.oss-gitconfig\n> \n> Expected configuration which doesn't find the conditional configuration:\n> \n> ~/.gitconfig\n> [includeIf \"gitdir:~/Work/git-repos/oss/\"]\n> path = .oss-gitconfig\n\nMy guess is, because includeIf might contain other conditionals than \n\"gitdir\", the generic convention is to always use an absolute path for \n\"path\".\n\n-- \nSebastian Schuberth\n\n"},{"id":"319291","messageId":"CACBZZX7CgeW1OK+g9Mbir62MMaCx4sHFZngUuWz_H241Sb355g@mail.gmail.com","threadId":"45924","inReplyTo":"b80c68fa-fe1e-3cf8-3c7e-527a4d941108@gmail.com","subject":"Re: Possible bug in includeIf / conditional includes","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-05-10T19:48:05Z","receivedAt":"2017-05-10T19:48:31Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Wed, May 10, 2017 at 8:58 PM, Sebastian Schuberth\n wrote:\n> On 2017-05-10 19:00, raphael.stolt@gmail.com wrote:\n>\n>> Current configuration which finds the conditional configuration.\n>>\n>> ~/.gitconfig\n>> [includeIf \"gitdir:~/Work/git-repos/oss/\"]\n>> path = ~/Work/git-repos/oss/.oss-gitconfig\n>>\n>> Expected configuration which doesn't find the conditional configuration:\n>>\n>> ~/.gitconfig\n>> [includeIf \"gitdir:~/Work/git-repos/oss/\"]\n>> path = .oss-gitconfig\n>\n>\n> My guess is, because includeIf might contain other conditionals than\n> \"gitdir\", the generic convention is to always use an absolute path for\n> \"path\".\n\n[CC'd OP Raphael Stolt, please reply-all]\n\nIn both cases the conditional is the same, but the path is relative\nv.s. absolute.\n\nRaphael: Does the config get included if you cd to\n~/Work/git-repos/oss/? From git-config(1):\n\n---cut---\nThe included file is expanded immediately, as if its contents had been\nfound at the location of the include directive. If the value of the\n`include.path` variable is a relative path, the path is considered to\nbe relative to the configuration file in which the include directive\nwas found. See below for examples.\n---cut---\n\nThe commit that added IncludeIf (3efd0bedc6) does something with\nrelative path (just skimming, need to get to other things), but unlike\n[Include] the docs don't explicitly mention what it's supposed to do\nwith that, and all the examples show absolute paths.\n\nSo whether this is a bug in the code or not it seems to definitely be\na doc bug, whatever it does with relative files should be in the docs.\n"},{"id":"319296","messageId":"CC77A0CE-88A5-4A3C-97AF-ED0180FE385B@gmail.com","threadId":"45924","inReplyTo":"CACBZZX7CgeW1OK+g9Mbir62MMaCx4sHFZngUuWz_H241Sb355g@mail.gmail.com","subject":"Re: Possible bug in includeIf / conditional includes","fromName":"Raphael Stolt","fromEmail":"raphael.stolt@gmail.com","sentAt":"2017-05-10T21:21:57Z","receivedAt":"2017-05-10T21:22:04Z","isPatch":false,"sender":{"key":"raphael.stolt@gmail.com","avatar":"https://gravatar.com/avatar/132faf5713fa951f4263fad02858a62e55c5d832ad775b33e49ba0cda2f2a028?d=mp&s=160"},"body":"> \n> Am 10.05.2017 um 21:48 schrieb Ævar Arnfjörð Bjarmason :\n> \n> On Wed, May 10, 2017 at 8:58 PM, Sebastian Schuberth\n> wrote:\n>> On 2017-05-10 19:00, raphael.stolt@gmail.com wrote:\n>> \n>>> Current configuration which finds the conditional configuration.\n>>> \n\na)\n\n>>> ~/.gitconfig\n>>> [includeIf \"gitdir:~/Work/git-repos/oss/\"]\n>>> path = ~/Work/git-repos/oss/.oss-gitconfig\n>>> \n>>> Expected configuration which doesn't find the conditional configuration:\n>>> \n\nb)\n\n>>> ~/.gitconfig\n>>> [includeIf \"gitdir:~/Work/git-repos/oss/\"]\n>>> path = .oss-gitconfig\n>> \n>> \n>> My guess is, because includeIf might contain other conditionals than\n>> \"gitdir\", the generic convention is to always use an absolute path for\n>> \"path\".\n> \n> [CC'd OP Raphael Stolt, please reply-all]\n> \n> In both cases the conditional is the same, but the path is relative\n> v.s. absolute.\n> \n> Raphael: Does the config get included if you cd to\n> ~/Work/git-repos/oss/? From git-config(1):\n\nGiven I’m in a repo in ~/Work/git-repos/oss/ e.g. ~/Work/git-repos/oss/project-repo-a and I’m using config a) \nthe config is used from ~/Work/git-repos/oss/.oss-gitconfig\n\nGiven I’m in a repo in ~/Work/git-repos/oss/ e.g. ~/Work/git-repos/oss/project-repo-a and I’m using config b) \nthe global config is used because there is no .oss-gitconfig in $HOME.\n\nI guess it’s an intended behavior since conditional configuration files __SHOULD__ reside in $HOME rather than \nin my case in ~/Work/git-repos/oss.\n\n> \n> ---cut---\n> The included file is expanded immediately, as if its contents had been\n> found at the location of the include directive. If the value of the\n> `include.path` variable is a relative path, the path is considered to\n> be relative to the configuration file in which the include directive\n> was found. See below for examples.\n> ---cut---\n> \n> The commit that added IncludeIf (3efd0bedc6) does something with\n> relative path (just skimming, need to get to other things), but unlike\n> [Include] the docs don't explicitly mention what it's supposed to do\n> with that, and all the examples show absolute paths.\n> \n> So whether this is a bug in the code or not it seems to definitely be\n> a doc bug, whatever it does with relative files should be in the docs.\n+ 1"},{"id":"319297","messageId":"C2EAA2DF-B7F4-4011-BB0F-4F3BA9E96890@gmail.com","threadId":"45924","inReplyTo":"CC77A0CE-88A5-4A3C-97AF-ED0180FE385B@gmail.com","subject":"Re: Possible bug in includeIf / conditional includes","fromName":"Raphael Stolt","fromEmail":"raphael.stolt@gmail.com","sentAt":"2017-05-10T21:37:13Z","receivedAt":"2017-05-10T21:37:22Z","isPatch":false,"sender":{"key":"raphael.stolt@gmail.com","avatar":"https://gravatar.com/avatar/132faf5713fa951f4263fad02858a62e55c5d832ad775b33e49ba0cda2f2a028?d=mp&s=160"},"body":"\n> Am 10.05.2017 um 23:21 schrieb Raphael Stolt :\n> \n>> \n>> Am 10.05.2017 um 21:48 schrieb Ævar Arnfjörð Bjarmason :\n>> \n>> On Wed, May 10, 2017 at 8:58 PM, Sebastian Schuberth\n>> wrote:\n>>> On 2017-05-10 19:00, raphael.stolt@gmail.com wrote:\n>>> \n>>>> Current configuration which finds the conditional configuration.\n>>>> \n> \n> a)\n> \n>>>> ~/.gitconfig\n>>>> [includeIf \"gitdir:~/Work/git-repos/oss/\"]\n>>>> path = ~/Work/git-repos/oss/.oss-gitconfig\n>>>> \n>>>> Expected configuration which doesn't find the conditional configuration:\n>>>> \n> \n> b)\n> \n>>>> ~/.gitconfig\n>>>> [includeIf \"gitdir:~/Work/git-repos/oss/\"]\n>>>> path = .oss-gitconfig\n>>> \n>>> \n>>> My guess is, because includeIf might contain other conditionals than\n>>> \"gitdir\", the generic convention is to always use an absolute path for\n>>> \"path\".\n>> \n>> [CC'd OP Raphael Stolt, please reply-all]\n>> \n>> In both cases the conditional is the same, but the path is relative\n>> v.s. absolute.\n>> \n>> Raphael: Does the config get included if you cd to\n>> ~/Work/git-repos/oss/? From git-config(1):\n> \n> Given I’m in a repo in ~/Work/git-repos/oss/ e.g. ~/Work/git-repos/oss/project-repo-a and I’m using config a) \n> the config is used from ~/Work/git-repos/oss/.oss-gitconfig\n> \n> Given I’m in a repo in ~/Work/git-repos/oss/ e.g. ~/Work/git-repos/oss/project-repo-a and I’m using config b) \n> the global config is used because there is no .oss-gitconfig in $HOME.\n\nGiven I’m in ~/Work/git-repos/oss and I’m using config b)\nalso the global config (~/.gitconfig) is used.\n\n> \n> I guess it’s an intended behavior since conditional configuration files __SHOULD__ reside in $HOME rather than \n> in my case in ~/Work/git-repos/oss.\n> \n>> \n>> ---cut---\n>> The included file is expanded immediately, as if its contents had been\n>> found at the location of the include directive. If the value of the\n>> `include.path` variable is a relative path, the path is considered to\n>> be relative to the configuration file in which the include directive\n>> was found. See below for examples.\n>> ---cut---\n>> \n>> The commit that added IncludeIf (3efd0bedc6) does something with\n>> relative path (just skimming, need to get to other things), but unlike\n>> [Include] the docs don't explicitly mention what it's supposed to do\n>> with that, and all the examples show absolute paths.\n>> \n>> So whether this is a bug in the code or not it seems to definitely be\n>> a doc bug, whatever it does with relative files should be in the docs.\n> + 1\n\n"},{"id":"319321","messageId":"20170511062616.f7rg6f5cgrqeh7gf@sigill.intra.peff.net","threadId":"45924","inReplyTo":"CACBZZX7CgeW1OK+g9Mbir62MMaCx4sHFZngUuWz_H241Sb355g@mail.gmail.com","subject":"Re: Possible bug in includeIf / conditional includes","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-05-11T06:26:16Z","receivedAt":"2017-05-11T06:26:29Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, May 10, 2017 at 09:48:05PM +0200, Ævar Arnfjörð Bjarmason wrote:\n\n> In both cases the conditional is the same, but the path is relative\n> v.s. absolute.\n> \n> Raphael: Does the config get included if you cd to\n> ~/Work/git-repos/oss/? From git-config(1):\n\nThat shouldn't matter for relative paths in the \"path\" value; they're\nnever based on the cwd. E.g., with this setup:\n\n export HOME=$PWD\n git config -f .gitconfig foo.bar \"base value\"\n git config -f .gitconfig includeIf.\"gitdir:$PWD/repo/\".path included\n git config -f included foo.bar \"HOME include\"\n git init -q repo && cd repo\n git config -f included foo.bar \"working tree include\"\n git config -f .git/included foo.bar \"GIT_DIR include\"\n git config foo.bar\n\nLooking at foo.bar should always give you one of\n\n HOME include - if you are in the repo that matches the includeIf\n base value - if you are not\n\nbut never the \"working tree\" or \"GIT_DIR\" includes.\n\n> ---cut---\n> The included file is expanded immediately, as if its contents had been\n> found at the location of the include directive. If the value of the\n> `include.path` variable is a relative path, the path is considered to\n> be relative to the configuration file in which the include directive\n> was found. See below for examples.\n> ---cut---\n> \n> The commit that added IncludeIf (3efd0bedc6) does something with\n> relative path (just skimming, need to get to other things), but unlike\n> [Include] the docs don't explicitly mention what it's supposed to do\n> with that, and all the examples show absolute paths.\n> \n> So whether this is a bug in the code or not it seems to definitely be\n> a doc bug, whatever it does with relative files should be in the docs.\n\nThe includeIf variables should behave exactly as the documentation you\nquoted above. The conditional impacts whether we respect the keys in\nthat section, but not the meaning of the keys.\n\nI thought that was clear, but as somebody who was involved in the\ndevelopment of both the original and the conditional includes, my\nopinion probably doesn't count. I wouldn't mind a patch to make that\nmore explicit in the documentation.\n\n-Peff\n"},{"id":"319322","messageId":"20170511062924.6euaynsbyocjcw3q@sigill.intra.peff.net","threadId":"45924","inReplyTo":"20170511062616.f7rg6f5cgrqeh7gf@sigill.intra.peff.net","subject":"Re: Possible bug in includeIf / conditional includes","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-05-11T06:29:24Z","receivedAt":"2017-05-11T06:29:30Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, May 11, 2017 at 02:26:16AM -0400, Jeff King wrote:\n\n> > So whether this is a bug in the code or not it seems to definitely be\n> > a doc bug, whatever it does with relative files should be in the docs.\n> \n> The includeIf variables should behave exactly as the documentation you\n> quoted above. The conditional impacts whether we respect the keys in\n> that section, but not the meaning of the keys.\n> \n> I thought that was clear, but as somebody who was involved in the\n> development of both the original and the conditional includes, my\n> opinion probably doesn't count. I wouldn't mind a patch to make that\n> more explicit in the documentation.\n\nI figured I'd just do this while we're thinking about it, since it\nshould be trivial. But it's actually there already:\n\n You can include a config file from another conditionally by setting a\n `includeIf..path` variable to the name of the file to be\n included. The variable's value is treated the same way as\n `include.path`.\n\nI'm open to suggestions to make that more obvious, though.\n\n-Peff\n"},{"id":"319327","messageId":"CACBZZX4ob04fG9ZZtvbdcqrYOKijoZohVdUCNyeayHZtdtNyxQ@mail.gmail.com","threadId":"45924","inReplyTo":"20170511062924.6euaynsbyocjcw3q@sigill.intra.peff.net","subject":"Re: Possible bug in includeIf / conditional includes","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-05-11T07:19:50Z","receivedAt":"2017-05-11T07:20:17Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Thu, May 11, 2017 at 8:29 AM, Jeff King wrote:\n> On Thu, May 11, 2017 at 02:26:16AM -0400, Jeff King wrote:\n>\n>> > So whether this is a bug in the code or not it seems to definitely be\n>> > a doc bug, whatever it does with relative files should be in the docs.\n>>\n>> The includeIf variables should behave exactly as the documentation you\n>> quoted above. The conditional impacts whether we respect the keys in\n>> that section, but not the meaning of the keys.\n>>\n>> I thought that was clear, but as somebody who was involved in the\n>> development of both the original and the conditional includes, my\n>> opinion probably doesn't count. I wouldn't mind a patch to make that\n>> more explicit in the documentation.\n>\n> I figured I'd just do this while we're thinking about it, since it\n> should be trivial. But it's actually there already:\n>\n> You can include a config file from another conditionally by setting a\n> `includeIf..path` variable to the name of the file to be\n> included. The variable's value is treated the same way as\n> `include.path`.\n>\n> I'm open to suggestions to make that more obvious, though.\n\nYes I started writing up a patch to make this better but once I\nstarted doing that it wasn't really any better.\n\nFWIW the reasons I didn't find this while quickly skimming the thing:\n\n1. It says \"The included file is expanded immediately, as if its\ncontents had been found at the location of the include directive.\". At\nfirst I thought this referred to glob expansion, not\ns/expanded/interpolated/, the example section uses \"expand\" in the\ncontext of pathnames, which caused the confusion.\n\nMaybe this would make that less confusing by saying the same thing\nwithout using the same phrasing to mean completely different things:\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 475e874d51..49855353c7 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -167,8 +167,8 @@ Example\n\n [include]\n path = /path/to/foo.inc ; include by absolute path\n- path = foo ; expand \"foo\" relative to the current file\n- path = ~/foo ; expand \"foo\" in your `$HOME` directory\n+ path = foo ; find & include \"foo\" relative to the current file\n+ path = ~/foo ; find & include \"foo\" in your `$HOME` directory\n\n ; include if $GIT_DIR is /path/to/foo/.git\n [includeIf \"gitdir:/path/to/foo/.git\"]\n\n2. There is no example of such expansion for IncludeIf, prose should\nalways be backed up by examples for the lazy reader when possible:\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 475e874d51..fc4b87cd7e 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -173,6 +173,8 @@ Example\n ; include if $GIT_DIR is /path/to/foo/.git\n [includeIf \"gitdir:/path/to/foo/.git\"]\n path = /path/to/foo.inc\n+ path = foo ; find & include \"foo\" relative to the current file\n+ path = ~/foo ; find & include \"foo\" in your `$HOME` directory\n\n ; include for all repositories inside /path/to/group\n [includeIf \"gitdir:/path/to/group/\"]\n\n3. When I read reference docs I almost never start at the beginning &\nread it all the way through, in this case I thought I could help\nsomeone out by maybe answering a question on the ML quickly, so I went\nto the examples section, found no example (fixed above), then searched\nfor \"relative\" or \"path\" in my pager and the only results were for the\n\"Includes\" section that has a paragraph that's only talking about\n\"include.path\".\n\nOf course we say \"same rules apply\" below, but I managed not to spot\nthat. Maybe this:\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 475e874d51..b35d9a7b80 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -95,8 +95,11 @@ Conditional includes\n\n You can include a config file from another conditionally by setting a\n `includeIf..path` variable to the name of the file to be\n-included. The variable's value is treated the same way as\n-`include.path`. `includeIf..path` can be given multiple times.\n+included.\n+\n+If variable's value is a relative path it's treated the same way as\n+`include.path`. `includeIf..path` can also be given\n+multiple times.\n\n The condition starts with a keyword followed by a colon and some data\n whose format and meaning depends on the keyword. Supported keywords\n\nWould make it easier to find. Here we say the same thing but include\nboth \"path\" & \"relative\".\n"},{"id":"319328","messageId":"20170511074257.xueofze3dv3xwrql@sigill.intra.peff.net","threadId":"45924","inReplyTo":"CACBZZX4ob04fG9ZZtvbdcqrYOKijoZohVdUCNyeayHZtdtNyxQ@mail.gmail.com","subject":"Re: Possible bug in includeIf / conditional includes","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-05-11T07:42:57Z","receivedAt":"2017-05-11T07:43:12Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, May 11, 2017 at 09:19:50AM +0200, Ævar Arnfjörð Bjarmason wrote:\n\n> 1. It says \"The included file is expanded immediately, as if its\n> contents had been found at the location of the include directive.\". At\n> first I thought this referred to glob expansion, not\n> s/expanded/interpolated/, the example section uses \"expand\" in the\n> context of pathnames, which caused the confusion.\n\nPerhaps it should say \"The contents of the included file are expanded\nimmediately, as if they had been found at...\"?\n\n> Maybe this would make that less confusing by saying the same thing\n> without using the same phrasing to mean completely different things:\n> \n> diff --git a/Documentation/config.txt b/Documentation/config.txt\n> index 475e874d51..49855353c7 100644\n> --- a/Documentation/config.txt\n> +++ b/Documentation/config.txt\n> @@ -167,8 +167,8 @@ Example\n> \n> [include]\n> path = /path/to/foo.inc ; include by absolute path\n> - path = foo ; expand \"foo\" relative to the current file\n> - path = ~/foo ; expand \"foo\" in your `$HOME` directory\n> + path = foo ; find & include \"foo\" relative to the current file\n> + path = ~/foo ; find & include \"foo\" in your `$HOME` directory\n\nYeah, probably makes sense to use a different word than \"expand\" here.\n\n> 2. There is no example of such expansion for IncludeIf, prose should\n> always be backed up by examples for the lazy reader when possible:\n> \n> diff --git a/Documentation/config.txt b/Documentation/config.txt\n> index 475e874d51..fc4b87cd7e 100644\n> --- a/Documentation/config.txt\n> +++ b/Documentation/config.txt\n> @@ -173,6 +173,8 @@ Example\n> ; include if $GIT_DIR is /path/to/foo/.git\n> [includeIf \"gitdir:/path/to/foo/.git\"]\n> path = /path/to/foo.inc\n> + path = foo ; find & include \"foo\" relative to the current file\n> + path = ~/foo ; find & include \"foo\" in your `$HOME` directory\n> \n> ; include for all repositories inside /path/to/group\n> [includeIf \"gitdir:/path/to/group/\"]\n\nYeah, makes sense.\n\n> 3. When I read reference docs I almost never start at the beginning &\n> read it all the way through, in this case I thought I could help\n> someone out by maybe answering a question on the ML quickly, so I went\n> to the examples section, found no example (fixed above), then searched\n> for \"relative\" or \"path\" in my pager and the only results were for the\n> \"Includes\" section that has a paragraph that's only talking about\n> \"include.path\".\n\nI do, too. And I'm all in favor of structuring things to accommodate\nthat flow. But at some point we have to assume the user actually reads\nthe documentation. :)\n\n> Of course we say \"same rules apply\" below, but I managed not to spot\n> that. Maybe this:\n> \n> diff --git a/Documentation/config.txt b/Documentation/config.txt\n> index 475e874d51..b35d9a7b80 100644\n> --- a/Documentation/config.txt\n> +++ b/Documentation/config.txt\n> @@ -95,8 +95,11 @@ Conditional includes\n> \n> You can include a config file from another conditionally by setting a\n> `includeIf..path` variable to the name of the file to be\n> -included. The variable's value is treated the same way as\n> -`include.path`. `includeIf..path` can be given multiple times.\n> +included.\n> +\n> +If variable's value is a relative path it's treated the same way as\n> +`include.path`. `includeIf..path` can also be given\n> +multiple times.\n\nI don't like this because it copies the rules for _one_ property to the\nconditional section. What happens when you're looking for some other\nproperty of include.path?\n\nI think in your case you found the \"relative\" section in the earlier\nparagraph, but there was no link there to the includeIf behavior. So\nshould that earlier paragraph just get the \"includeIf.path behaves the\nsame way\" mention?\n\nI suspect that whole paragraph under Includes could be reworded to make\nit clear that anything it is saying applies equally to include.$key and\nincludeIf.*.$key, and then that would future-proof us for other\nmodifications.\n\n-Peff\n"},{"id":"319333","messageId":"CACBZZX6hpL0=Zw0kvB-Ww95uGvuJ8129MTwkmv7DOEE1i66a_Q@mail.gmail.com","threadId":"45924","inReplyTo":"20170511074257.xueofze3dv3xwrql@sigill.intra.peff.net","subject":"Re: Possible bug in includeIf / conditional includes","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-05-11T07:49:09Z","receivedAt":"2017-05-11T07:49:36Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Thu, May 11, 2017 at 9:42 AM, Jeff King wrote:\n> On Thu, May 11, 2017 at 09:19:50AM +0200, Ævar Arnfjörð Bjarmason wrote:\n>\n>> 1. It says \"The included file is expanded immediately, as if its\n>> contents had been found at the location of the include directive.\". At\n>> first I thought this referred to glob expansion, not\n>> s/expanded/interpolated/, the example section uses \"expand\" in the\n>> context of pathnames, which caused the confusion.\n>\n> Perhaps it should say \"The contents of the included file are expanded\n> immediately, as if they had been found at...\"?\n>\n>> Maybe this would make that less confusing by saying the same thing\n>> without using the same phrasing to mean completely different things:\n>>\n>> diff --git a/Documentation/config.txt b/Documentation/config.txt\n>> index 475e874d51..49855353c7 100644\n>> --- a/Documentation/config.txt\n>> +++ b/Documentation/config.txt\n>> @@ -167,8 +167,8 @@ Example\n>>\n>> [include]\n>> path = /path/to/foo.inc ; include by absolute path\n>> - path = foo ; expand \"foo\" relative to the current file\n>> - path = ~/foo ; expand \"foo\" in your `$HOME` directory\n>> + path = foo ; find & include \"foo\" relative to the current file\n>> + path = ~/foo ; find & include \"foo\" in your `$HOME` directory\n>\n> Yeah, probably makes sense to use a different word than \"expand\" here.\n>\n>> 2. There is no example of such expansion for IncludeIf, prose should\n>> always be backed up by examples for the lazy reader when possible:\n>>\n>> diff --git a/Documentation/config.txt b/Documentation/config.txt\n>> index 475e874d51..fc4b87cd7e 100644\n>> --- a/Documentation/config.txt\n>> +++ b/Documentation/config.txt\n>> @@ -173,6 +173,8 @@ Example\n>> ; include if $GIT_DIR is /path/to/foo/.git\n>> [includeIf \"gitdir:/path/to/foo/.git\"]\n>> path = /path/to/foo.inc\n>> + path = foo ; find & include \"foo\" relative to the current file\n>> + path = ~/foo ; find & include \"foo\" in your `$HOME` directory\n>>\n>> ; include for all repositories inside /path/to/group\n>> [includeIf \"gitdir:/path/to/group/\"]\n>\n> Yeah, makes sense.\n>\n>> 3. When I read reference docs I almost never start at the beginning &\n>> read it all the way through, in this case I thought I could help\n>> someone out by maybe answering a question on the ML quickly, so I went\n>> to the examples section, found no example (fixed above), then searched\n>> for \"relative\" or \"path\" in my pager and the only results were for the\n>> \"Includes\" section that has a paragraph that's only talking about\n>> \"include.path\".\n>\n> I do, too. And I'm all in favor of structuring things to accommodate\n> that flow. But at some point we have to assume the user actually reads\n> the documentation. :)\n>\n>> Of course we say \"same rules apply\" below, but I managed not to spot\n>> that. Maybe this:\n>>\n>> diff --git a/Documentation/config.txt b/Documentation/config.txt\n>> index 475e874d51..b35d9a7b80 100644\n>> --- a/Documentation/config.txt\n>> +++ b/Documentation/config.txt\n>> @@ -95,8 +95,11 @@ Conditional includes\n>>\n>> You can include a config file from another conditionally by setting a\n>> `includeIf..path` variable to the name of the file to be\n>> -included. The variable's value is treated the same way as\n>> -`include.path`. `includeIf..path` can be given multiple times.\n>> +included.\n>> +\n>> +If variable's value is a relative path it's treated the same way as\n>> +`include.path`. `includeIf..path` can also be given\n>> +multiple times.\n>\n> I don't like this because it copies the rules for _one_ property to the\n> conditional section. What happens when you're looking for some other\n> property of include.path?\n\nYeah, as I said once I wrote it up I found it wasn't really any\nbetter, but just wanted to send an explanation for why I didn't find\nit while I remembered, as a sort of case study.\n\n> I think in your case you found the \"relative\" section in the earlier\n> paragraph, but there was no link there to the includeIf behavior. So\n> should that earlier paragraph just get the \"includeIf.path behaves the\n> same way\" mention?\n>\n> I suspect that whole paragraph under Includes could be reworded to make\n> it clear that anything it is saying applies equally to include.$key and\n> includeIf.*.$key, and then that would future-proof us for other\n> modifications.\n"},{"id":"319334","messageId":"xmqqbmqzbzh0.fsf@gitster.mtv.corp.google.com","threadId":"45924","inReplyTo":"20170511074257.xueofze3dv3xwrql@sigill.intra.peff.net","subject":"Re: Possible bug in includeIf / conditional includes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-05-11T07:54:19Z","receivedAt":"2017-05-11T07:54:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Thu, May 11, 2017 at 09:19:50AM +0200, Ævar Arnfjörð Bjarmason wrote:\n>\n>> 1. It says \"The included file is expanded immediately, as if its\n>> contents had been found at the location of the include directive.\". At\n>> first I thought this referred to glob expansion, not\n>> s/expanded/interpolated/, the example section uses \"expand\" in the\n>> context of pathnames, which caused the confusion.\n>\n> Perhaps it should say \"The contents of the included file are expanded\n> immediately, as if they had been found at...\"?\n\nOr s/expanded/inserted/, perhaps? The word \"expand\" does not quite\nclick to me in this context. Just like Ævar, I associate the word\nwith an act of replacing some template-with-blank with the result of\nblanks-in-the-template-filled.\n\nRegarding 2. and 3., I agree with your comments.\n\nThanks.\n"},{"id":"319335","messageId":"20170511075437.yjxs6oit7ibe7rkq@sigill.intra.peff.net","threadId":"45924","inReplyTo":"CACBZZX6hpL0=Zw0kvB-Ww95uGvuJ8129MTwkmv7DOEE1i66a_Q@mail.gmail.com","subject":"Re: Possible bug in includeIf / conditional includes","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-05-11T07:54:37Z","receivedAt":"2017-05-11T07:54:46Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, May 11, 2017 at 09:49:09AM +0200, Ævar Arnfjörð Bjarmason wrote:\n\n> > I don't like this because it copies the rules for _one_ property to the\n> > conditional section. What happens when you're looking for some other\n> > property of include.path?\n> \n> Yeah, as I said once I wrote it up I found it wasn't really any\n> better, but just wanted to send an explanation for why I didn't find\n> it while I remembered, as a sort of case study.\n> [...]\n> > I suspect that whole paragraph under Includes could be reworded to make\n> > it clear that anything it is saying applies equally to include.$key and\n> > includeIf.*.$key, and then that would future-proof us for other\n> > modifications.\n\nWhat about this:\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 475e874d5..e44ad21eb 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -80,13 +80,13 @@ Includes\n ~~~~~~~~\n \n You can include a config file from another by setting the special\n-`include.path` variable to the name of the file to be included. The\n-variable takes a pathname as its value, and is subject to tilde\n-expansion. `include.path` can be given multiple times.\n+`include.path` and `includeIf.*.path` variables to the name of the file\n+to be included. The variable takes a pathname as its value, and is\n+subject to tilde expansion. These variables can be given multiple times.\n \n The included file is expanded immediately, as if its contents had been\n found at the location of the include directive. If the value of the\n-`include.path` variable is a relative path, the path is considered to\n+variable is a relative path, the path is considered to\n be relative to the configuration file in which the include directive\n was found. See below for examples.\n \n@@ -95,8 +95,7 @@ Conditional includes\n \n You can include a config file from another conditionally by setting a\n `includeIf..path` variable to the name of the file to be\n-included. The variable's value is treated the same way as\n-`include.path`. `includeIf..path` can be given multiple times.\n+included (see the \"Includes\" section above for more details).\n \n The condition starts with a keyword followed by a colon and some data\n whose format and meaning depends on the keyword. Supported keywords\n"},{"id":"319336","messageId":"20170511075624.572rujfaedzihpn4@sigill.intra.peff.net","threadId":"45924","inReplyTo":"xmqqbmqzbzh0.fsf@gitster.mtv.corp.google.com","subject":"Re: Possible bug in includeIf / conditional includes","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-05-11T07:56:24Z","receivedAt":"2017-05-11T07:56:31Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, May 11, 2017 at 12:54:19AM -0700, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > On Thu, May 11, 2017 at 09:19:50AM +0200, Ævar Arnfjörð Bjarmason wrote:\n> >\n> >> 1. It says \"The included file is expanded immediately, as if its\n> >> contents had been found at the location of the include directive.\". At\n> >> first I thought this referred to glob expansion, not\n> >> s/expanded/interpolated/, the example section uses \"expand\" in the\n> >> context of pathnames, which caused the confusion.\n> >\n> > Perhaps it should say \"The contents of the included file are expanded\n> > immediately, as if they had been found at...\"?\n> \n> Or s/expanded/inserted/, perhaps? The word \"expand\" does not quite\n> click to me in this context. Just like Ævar, I associate the word\n> with an act of replacing some template-with-blank with the result of\n> blanks-in-the-template-filled.\n\nYeah, that is much better. I think \"expand\" here originally meant \"read\nthe contents of\", but when we talk about the contents already there is\nnothing left to expand.\n\nI agree \"inserted\" is probably the right word (or even just \"read\" or\n\"parsed\" or something).\n\n-Peff\n"},{"id":"319339","messageId":"20170511090905.tvkb4bk2ddjzjip4@sigill.intra.peff.net","threadId":"45924","inReplyTo":"20170511075437.yjxs6oit7ibe7rkq@sigill.intra.peff.net","subject":"[PATCH 0/4] doc improvements for config includes","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-05-11T09:09:05Z","receivedAt":"2017-05-11T09:09:14Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, May 11, 2017 at 03:54:37AM -0400, Jeff King wrote:\n\n> On Thu, May 11, 2017 at 09:49:09AM +0200, Ævar Arnfjörð Bjarmason wrote:\n> \n> > > I don't like this because it copies the rules for _one_ property to the\n> > > conditional section. What happens when you're looking for some other\n> > > property of include.path?\n> > \n> > Yeah, as I said once I wrote it up I found it wasn't really any\n> > better, but just wanted to send an explanation for why I didn't find\n> > it while I remembered, as a sort of case study.\n> > [...]\n> > > I suspect that whole paragraph under Includes could be reworded to make\n> > > it clear that anything it is saying applies equally to include.$key and\n> > > includeIf.*.$key, and then that would future-proof us for other\n> > > modifications.\n> \n> What about this:\n\nI think this is the right path, but I actually ended up with an\nintroductory paragraph about the two sections. I hope it makes the same\npoint but is a bit less clunky.\n\nHere's a series that I think covers all the bits discussed here, and a\nfew others.\n\n [1/4]: docs/config: clarify include/includeIf relationship\n [2/4]: docs/config: give a relative includeIf example\n [3/4]: docs/config: avoid the term \"expand\" for includes\n [4/4]: docs/config: consistify include.path examples\n\n Documentation/config.txt | 31 +++++++++++++++++++++----------\n 1 file changed, 21 insertions(+), 10 deletions(-)\n\n-Peff\n"},{"id":"319340","messageId":"20170511091047.2dw52pnriulhjky3@sigill.intra.peff.net","threadId":"45924","inReplyTo":"20170511090905.tvkb4bk2ddjzjip4@sigill.intra.peff.net","subject":"[PATCH 1/4] docs/config: clarify include/includeIf relationship","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-05-11T09:10:47Z","receivedAt":"2017-05-11T09:10:54Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"The \"includeIf\" directives behave exactly like include ones,\nexcept they only kick in when the conditional is true. That\nwas mentioned in the \"conditional\" section, but let's make\nit more clear for the whole \"includes\" section, since people\ndon't necessarily read the documentation top to bottom.\n\nSigned-off-by: Jeff King \n---\n Documentation/config.txt | 17 +++++++++++------\n 1 file changed, 11 insertions(+), 6 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 475e874d5..d5a453ed3 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -79,14 +79,20 @@ escape sequences) are invalid.\n Includes\n ~~~~~~~~\n \n+The `include` and `includeIf` sections allow you include config\n+directives from another source. These sections behave identically to\n+each other with the exception that `includeIf` sections may be ignored\n+if their condition does not evaluate to true; see \"Conditional includes\"\n+below.\n+\n You can include a config file from another by setting the special\n-`include.path` variable to the name of the file to be included. The\n-variable takes a pathname as its value, and is subject to tilde\n-expansion. `include.path` can be given multiple times.\n+`include.path` (or `includeIf.*.path`) variable to the name of the file\n+to be included. The variable takes a pathname as its value, and is\n+subject to tilde expansion. These variables can be given multiple times.\n \n The included file is expanded immediately, as if its contents had been\n found at the location of the include directive. If the value of the\n-`include.path` variable is a relative path, the path is considered to\n+variable is a relative path, the path is considered to\n be relative to the configuration file in which the include directive\n was found. See below for examples.\n \n@@ -95,8 +101,7 @@ Conditional includes\n \n You can include a config file from another conditionally by setting a\n `includeIf..path` variable to the name of the file to be\n-included. The variable's value is treated the same way as\n-`include.path`. `includeIf..path` can be given multiple times.\n+included.\n \n The condition starts with a keyword followed by a colon and some data\n whose format and meaning depends on the keyword. Supported keywords\n-- \n2.13.0.447.g4d26bc97c\n\n"},{"id":"319341","messageId":"20170511091106.cpk5emqtvp4cdeoi@sigill.intra.peff.net","threadId":"45924","inReplyTo":"20170511090905.tvkb4bk2ddjzjip4@sigill.intra.peff.net","subject":"[PATCH 2/4] docs/config: give a relative includeIf example","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-05-11T09:11:06Z","receivedAt":"2017-05-11T09:11:13Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"The changes in the previous commit hopefully clarify that\nthe evaluation of an include \"path\" variable is the same no\nmatter if it's in a conditional section or not. But since\nthis question came up on the list, let's add an example that\nmakes it obvious.\n\nSigned-off-by: Jeff King \n---\n Documentation/config.txt | 6 ++++++\n 1 file changed, 6 insertions(+)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex d5a453ed3..929776954 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -187,6 +187,12 @@ Example\n \t[includeIf \"gitdir:~/to/group/\"]\n \t\tpath = /path/to/foo.inc\n \n+\t; relative paths are always relative to the including\n+\t; file (if the condition is true); their location is not\n+\t; affected by the condition\n+\t[includeIf \"gitdir:/path/to/group/\"]\n+\t\tpath = foo.inc\n+\n Values\n ~~~~~~\n \n-- \n2.13.0.447.g4d26bc97c\n\n"},{"id":"319342","messageId":"20170511091304.ivauge72dncv65fs@sigill.intra.peff.net","threadId":"45924","inReplyTo":"20170511090905.tvkb4bk2ddjzjip4@sigill.intra.peff.net","subject":"[PATCH 3/4] docs/config: avoid the term \"expand\" for includes","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-05-11T09:13:04Z","receivedAt":"2017-05-11T09:13:11Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"Using the word \"expand\" to refer to including the contents\nof another config file isn't really accurate, since it's a\nverbatim insertion. And it can cause confusion with the\nexpanding of the path itself via things like \"~\".\n\nLet's clarify when we are referring to the contents versus\nthe filename, and use appropriate verbs in each case.\n\nSigned-off-by: Jeff King \n---\nI dropped the \"& insert\" from your suggestion, because I think it\nclear in the context of the earlier \"include by absolute path\" (and I\nthink it reads better).\n\n Documentation/config.txt | 8 ++++----\n 1 file changed, 4 insertions(+), 4 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 929776954..70f79ac39 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -90,8 +90,8 @@ You can include a config file from another by setting the special\n to be included. The variable takes a pathname as its value, and is\n subject to tilde expansion. These variables can be given multiple times.\n \n-The included file is expanded immediately, as if its contents had been\n-found at the location of the include directive. If the value of the\n+The contents of the included file are inserted immediately, as if they\n+had been found at the location of the include directive. If the value of the\n variable is a relative path, the path is considered to\n be relative to the configuration file in which the include directive\n was found. See below for examples.\n@@ -172,8 +172,8 @@ Example\n \n \t[include]\n \t\tpath = /path/to/foo.inc ; include by absolute path\n-\t\tpath = foo ; expand \"foo\" relative to the current file\n-\t\tpath = ~/foo ; expand \"foo\" in your `$HOME` directory\n+\t\tpath = foo ; find \"foo\" relative to the current file\n+\t\tpath = ~/foo ; find \"foo\" in your `$HOME` directory\n \n \t; include if $GIT_DIR is /path/to/foo/.git\n \t[includeIf \"gitdir:/path/to/foo/.git\"]\n-- \n2.13.0.447.g4d26bc97c\n\n"},{"id":"319343","messageId":"20170511091430.jwpbyca3m32wterq@sigill.intra.peff.net","threadId":"45924","inReplyTo":"20170511090905.tvkb4bk2ddjzjip4@sigill.intra.peff.net","subject":"[PATCH 4/4] docs/config: consistify include.path examples","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-05-11T09:14:30Z","receivedAt":"2017-05-11T09:14:36Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"Most of the include examples use \"foo.inc\", but some use\n\"foo\". Since the string of examples are meant to show\nvariations and how they differ, it's a good idea to change\nonly one thing at a time. The filename differences are not\nrelevant to what we're trying to show.\n\nSigned-off-by: Jeff King \n---\nAnd yes, I just invented the word consistify. \"make X consistent\" hides\nthe meaning at the end, and I couldn't think of a more concise verb.\nPrescriptivists beware. :)\n\n Documentation/config.txt | 4 ++--\n 1 file changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 70f79ac39..7b08df732 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -172,8 +172,8 @@ Example\n \n \t[include]\n \t\tpath = /path/to/foo.inc ; include by absolute path\n-\t\tpath = foo ; find \"foo\" relative to the current file\n-\t\tpath = ~/foo ; find \"foo\" in your `$HOME` directory\n+\t\tpath = foo.inc ; find \"foo.inc\" relative to the current file\n+\t\tpath = ~/foo.inc ; find \"foo.inc\" in your `$HOME` directory\n \n \t; include if $GIT_DIR is /path/to/foo/.git\n \t[includeIf \"gitdir:/path/to/foo/.git\"]\n-- \n2.13.0.447.g4d26bc97c\n"},{"id":"319374","messageId":"CACBZZX4BEOO+DeO-OzJzHT88Y2k7_ZmFRPJKJ9e6HMb9eMonZA@mail.gmail.com","threadId":"45924","inReplyTo":"20170511090905.tvkb4bk2ddjzjip4@sigill.intra.peff.net","subject":"Re: [PATCH 0/4] doc improvements for config includes","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-05-11T09:29:15Z","receivedAt":"2017-05-11T09:29:42Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Thu, May 11, 2017 at 11:09 AM, Jeff King wrote:\n> On Thu, May 11, 2017 at 03:54:37AM -0400, Jeff King wrote:\n>\n>> On Thu, May 11, 2017 at 09:49:09AM +0200, Ævar Arnfjörð Bjarmason wrote:\n>>\n>> > > I don't like this because it copies the rules for _one_ property to the\n>> > > conditional section. What happens when you're looking for some other\n>> > > property of include.path?\n>> >\n>> > Yeah, as I said once I wrote it up I found it wasn't really any\n>> > better, but just wanted to send an explanation for why I didn't find\n>> > it while I remembered, as a sort of case study.\n>> > [...]\n>> > > I suspect that whole paragraph under Includes could be reworded to make\n>> > > it clear that anything it is saying applies equally to include.$key and\n>> > > includeIf.*.$key, and then that would future-proof us for other\n>> > > modifications.\n>>\n>> What about this:\n>\n> I think this is the right path, but I actually ended up with an\n> introductory paragraph about the two sections. I hope it makes the same\n> point but is a bit less clunky.\n>\n> Here's a series that I think covers all the bits discussed here, and a\n> few others.\n>\n> [1/4]: docs/config: clarify include/includeIf relationship\n> [2/4]: docs/config: give a relative includeIf example\n> [3/4]: docs/config: avoid the term \"expand\" for includes\n> [4/4]: docs/config: consistify include.path examples\n\nThis whole thing looks great to me. Thanks!\n\nReviewed-by: Ævar Arnfjörð Bjarmason \n\n> Documentation/config.txt | 31 +++++++++++++++++++++----------\n> 1 file changed, 21 insertions(+), 10 deletions(-)\n>\n> -Peff\n"},{"id":"319378","messageId":"xmqqh90rafxk.fsf@gitster.mtv.corp.google.com","threadId":"45924","inReplyTo":"20170511091430.jwpbyca3m32wterq@sigill.intra.peff.net","subject":"Re: [PATCH 4/4] docs/config: consistify include.path examples","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-05-11T09:41:43Z","receivedAt":"2017-05-11T09:41:50Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Most of the include examples use \"foo.inc\", but some use\n> \"foo\". Since the string of examples are meant to show\n> variations and how they differ, it's a good idea to change\n> only one thing at a time. The filename differences are not\n> relevant to what we're trying to show.\n>\n> Signed-off-by: Jeff King \n> ---\n> And yes, I just invented the word consistify. \"make X consistent\" hides\n> the meaning at the end, and I couldn't think of a more concise verb.\n\nYeah, \"remove unnecessary variants from X\" is the best I could do.\nIn any case, all four looked sensible.\n\nThanks.\n"},{"id":"319412","messageId":"0013fb73-12f2-a365-963e-ed517ea53dc7@ramsayjones.plus.com","threadId":"45924","inReplyTo":"20170511091047.2dw52pnriulhjky3@sigill.intra.peff.net","subject":"Re: [PATCH 1/4] docs/config: clarify include/includeIf relationship","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2017-05-11T16:47:28Z","receivedAt":"2017-05-11T16:47:36Z","isPatch":true,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"\n\nOn 11/05/17 10:10, Jeff King wrote:\n> The \"includeIf\" directives behave exactly like include ones,\n> except they only kick in when the conditional is true. That\n> was mentioned in the \"conditional\" section, but let's make\n> it more clear for the whole \"includes\" section, since people\n> don't necessarily read the documentation top to bottom.\n> \n> Signed-off-by: Jeff King \n> ---\n> Documentation/config.txt | 17 +++++++++++------\n> 1 file changed, 11 insertions(+), 6 deletions(-)\n> \n> diff --git a/Documentation/config.txt b/Documentation/config.txt\n> index 475e874d5..d5a453ed3 100644\n> --- a/Documentation/config.txt\n> +++ b/Documentation/config.txt\n> @@ -79,14 +79,20 @@ escape sequences) are invalid.\n> Includes\n> ~~~~~~~~\n> \n> +The `include` and `includeIf` sections allow you include config\n\ns/you include/you to include/\n\nATB,\nRamsay Jones\n"},{"id":"319520","messageId":"20170512092825.wfxnnlk4qiced5ow@sigill.intra.peff.net","threadId":"45924","inReplyTo":"0013fb73-12f2-a365-963e-ed517ea53dc7@ramsayjones.plus.com","subject":"Re: [PATCH 1/4] docs/config: clarify include/includeIf relationship","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-05-12T09:28:25Z","receivedAt":"2017-05-12T18:45:07Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, May 11, 2017 at 05:47:28PM +0100, Ramsay Jones wrote:\n\n> > diff --git a/Documentation/config.txt b/Documentation/config.txt\n> > index 475e874d5..d5a453ed3 100644\n> > --- a/Documentation/config.txt\n> > +++ b/Documentation/config.txt\n> > @@ -79,14 +79,20 @@ escape sequences) are invalid.\n> > Includes\n> > ~~~~~~~~\n> > \n> > +The `include` and `includeIf` sections allow you include config\n> \n> s/you include/you to include/\n\nOof, yeah. Too many revisions, not enough proofreading. I don't think\nthese otherwise need re-rolled, so hopefully Junio can just mark it up.\n\nThanks.\n\n-Peff\n"}]}