git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Possible bug in includeIf / conditional includes

From
Jeff King <peff@peff.net>
Date
May 11, 2017, 06:26 UTC
Message-ID
<20170511062616.f7rg6f5cgrqeh7gf@sigill.intra.peff.net>
In-Reply-To
<CACBZZX7CgeW1OK+g9Mbir62MMaCx4sHFZngUuWz_H241Sb355g@mail.gmail.com>
On Wed, May 10, 2017 at 09:48:05PM +0200, Ævar Arnfjörð Bjarmason wrote:
Show 5 quoted lines
> In both cases the conditional is the same, but the path is relative
> v.s. absolute.
> 
> Raphael: Does the config get included if you cd to
> ~/Work/git-repos/oss/? From git-config(1):

That shouldn't matter for relative paths in the "path" value; they're never based on the cwd. E.g., with this setup:

  export HOME=$PWD
  git config -f .gitconfig foo.bar "base value"
  git config -f .gitconfig includeIf."gitdir:$PWD/repo/".path included
  git config -f included foo.bar "HOME include"
  git init -q repo && cd repo
  git config -f included foo.bar "working tree include"
  git config -f .git/included foo.bar "GIT_DIR include"
  git config foo.bar
Looking at foo.bar should always give you one of
  HOME include - if you are in the repo that matches the includeIf
  base value - if you are not
but never the "working tree" or "GIT_DIR" includes.
Show 15 quoted lines
> ---cut---
> The included file is expanded immediately, as if its contents had been
> found at the location of the include directive. If the value of the
> `include.path` variable is a relative path, the path is considered to
> be relative to the configuration file in which the include directive
> was found.  See below for examples.
> ---cut---
> 
> The commit that added IncludeIf (3efd0bedc6) does something with
> relative path (just skimming, need to get to other things), but unlike
> [Include] the docs don't explicitly mention what it's supposed to do
> with that, and all the examples show absolute paths.
> 
> So whether this is a bug in the code or not it seems to definitely be
> a doc bug, whatever it does with relative files should be in the docs.

The includeIf variables should behave exactly as the documentation you quoted above. The conditional impacts whether we respect the keys in that section, but not the meaning of the keys.

I thought that was clear, but as somebody who was involved in the development of both the original and the conditional includes, my opinion probably doesn't count. I wouldn't mind a patch to make that more explicit in the documentation.

-Peff
Previous: Raphael StoltNext: Jeff King
Message 6 of 22 in “Possible bug in includeIf / conditional includes”
  1. raphael.stolt@gmail.comMay 10, 2017
  2. Sebastian SchuberthMay 10, 2017
  3. Ævar Arnfjörð BjarmasonMay 10, 2017
  4. Raphael StoltMay 10, 2017
  5. Raphael StoltMay 10, 2017
  6. Jeff KingMay 11, 2017
  7. Jeff KingMay 11, 2017
  8. Ævar Arnfjörð BjarmasonMay 11, 2017
  9. Jeff KingMay 11, 2017
  10. Ævar Arnfjörð BjarmasonMay 11, 2017
  11. Jeff KingMay 11, 2017
  12. 0/4 doc improvements for config includesJeff King, May 11, 2017
  13. 1/4 docs/config: clarify include/includeIf relationshipJeff King, May 11, 2017
  14. Ramsay JonesMay 11, 2017
  15. Jeff KingMay 12, 2017
  16. 2/4 docs/config: give a relative includeIf exampleJeff King, May 11, 2017
  17. 3/4 docs/config: avoid the term "expand" for includesJeff King, May 11, 2017
  18. 4/4 docs/config: consistify include.path examplesJeff King, May 11, 2017
  19. Junio C HamanoMay 11, 2017
  20. Ævar Arnfjörð BjarmasonMay 11, 2017
  21. Junio C HamanoMay 11, 2017
  22. Jeff KingMay 11, 2017

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.