Git Mailing List Archive mirror
 help / color / mirror / Atom feed
From: "brian m. carlson" <>
To: Simon Thurston <>
Subject: Re: [Bug Report] git config includeIf not traversing symlink subdirectories
Date: Sat, 4 May 2024 01:06:36 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

[-- Attachment #1: Type: text/plain, Size: 3097 bytes --]

[Please keep the list in CC so others can chime in.]

On 2024-05-03 at 23:41:14, Simon Thurston wrote:
> Thanks Brian. The issue I'm having is that I have two main development directories, for "home" and for "work". I have includeIf statements in my primary .gitconfig that sources different public/private keys for each subdirectory. Under the "work" subdirectory, I have folders for projects, and then a "Deploy" folder that contains symlinks to folders over the network, so I can quickly cd and git clone/pull to deploy things manually, as well as use with some CD powershell scripts I have. The important thing to note is that the directories that are symlinked to repositories.
> In short, if I have an includeIf that encompasses a parent directory, any subdirectory symlink that points to a repository on a local server does not properly resolve to include the settings from the includeIf.
> /work/Project/.git can be detected, but /work/Deploy/ProjectSymlink/.git cannot, and thus any includeIf statement that checks for repositories under /work/** does not properly detect the repositories that are symlinked.

Yes, I think this is intentional.  Git doesn't consider the repositories
which are on the UNC drive to be under /work/Deploy, because the
canonical path is not in that location.

> I have tried to get around this by adding an extra includeIf statement to include //the/direct/unc/path/** but that was not able to resolve properly either. Mapped network drives with drive letters also don't resolve, and the only workaround I had was to blanket apply the config file to every directory, which is not ideal for the environment I work in.

Yes, the mapped network drives will be resolved to the UNC path with
`GetPathNameByHandle`, which is why that syntax doesn't work.

> If the behavior around symlinks is intentional, then that is fine and can be worked around, but not being able to specify UNC style paths in the configs is something that makes it difficult to work on SMB shares with specific configs needed.

As I said, I don't use Windows except extremely incidentally, so it's
difficult for me to speak with any authority on UNC paths.  It's
possible that they are supported using a syntax I don't know about, or
it's possible that they simply don't work at all.  If it's the latter,
I'm sure we'd accept a patch to fix it.

What I might suggest is switching into one of the symlinked directories
and running `git rev-parse --absolute-git-dir`, which should show you
what Git thinks the directory is.  You can then write that path directly
in the configuration file, nothing that inside the double quotes,
backslashes must be escaped (so if the path is \\the\direct\unc\path,
you'd write '[includeIf "\\\\the\\direct\\unc\\path"]').  You may also
want to use gitdir/i if you're not already, since my guess is that your
paths are actually case-insensitive.

If that doesn't work, hopefully someone else more familiar than me with
Windows can speak more to this.
brian m. carlson (they/them or he/him)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

      parent reply	other threads:[~2024-05-04  1:06 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-03 21:31 [Bug Report] git config includeIf not traversing symlink subdirectories Simon Thurston
2024-05-03 23:06 ` brian m. carlson
     [not found]   ` <>
2024-05-04  1:06     ` brian m. carlson [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).