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

Re: Why does the includeif woks how it does?

From
DHDominik von Haller <vonhaller@fastec.de>
Date
Feb 20, 2024, 06:54 UTC
Message-ID
<FR2P281MB16867E5D8C722A787F6CFEDABA502@FR2P281MB1686.DEUP281.PROD.OUTLOOK.COM>
Thanks, you all for your insights. <3
So to summarize, it was implemented through a gitdir because of possible confusions with the working directory. And there is no other implementation because the use case is not there.
For the new implementation I would always use the working directory. If set with git -C than use that. Should also not be a Problem because the working directory it is set internally anyway.
As far as the possible implementation of this goes, I would prefer an includeif with an extra option dir instead of gitdir. This would prevent confusion between includewhere and includeif.

The mentioned Problems seem to be easily figured out. Every includeif == true will get included. Every more specific path will overwrite properties if set before. Gitdir is more specific than just dir. Somewhat like that I would say is very intuitive.

Another possible approach which I would also say is logical is a top-down approach. Every Includeif would be executed from top to bottom. Every true includeif will be included and as before would overwrite properties if necessary. 

Best regards Dominik von Haller 

Message 1 of 1 in “Re: Why does the includeif woks how it does?”
  1. Dominik von HallerFeb 20, 2024

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.