.gitconfig includeif not available inside container

[brettmillerb]

• VSCode Version:
  Version: 1.41.0-insider
  Commit: 599c076d91be1374cf51004cec610f3bcaf4c9cd
  Date: 2019-11-22T07:19:06.796Z
  Electron: 6.1.5
  Chrome: 76.0.3809.146
  Node.js: 12.4.0
  V8: 7.6.303.31-electron.0

• Local OS Version:
  OS: Darwin x64 18.7.0

• Remote OS Version:
  Debian 9 (mcr.microsoft.com/powershell)

• Remote Extension/Connection Type: Docker

Steps to Reproduce:

1. includeif in gitconfig is not honoured inside the developement container.

Local .gitconfig contains

[includeIf "gitdir/i:~/git/gitpersonal/"]
	path = ~/.gitconfig-personal

git config --list --show-origin

Local

file:/Users/brett.miller/.gitconfig     user.name=Brett Miller
file:/Users/brett.miller/.gitconfig     user.email=brett.miller@org.com
file:/Users/brett.miller/.gitconfig     includeif.gitdir/i:~/git/gitpersonal/.path=~/.gitconfig-personal
file:/Users/brett.miller/.gitconfig-personal    user.name=Brett Miller
file:/Users/brett.miller/.gitconfig-personal    user.email=brett@millerb.co.uk
file:/Users/brett.miller/.gitconfig     core.editor=code-insiders --wait

Devcontainer

file:/root/.gitconfig   user.name=Brett Miller
file:/root/.gitconfig   user.email=brett.miller@org.com
file:/root/.gitconfig   includeif.gitdir/i:~/git/gitpersonal/.path=~/.gitconfig-personal
file:/root/.gitconfig   core.editor=code-insiders --wait

Seen #1811 but didn't think it was the same thing.

[sanmai-NL]

@brettmillerb Are the included files accessible from the container, though?

[brettmillerb]

@brettmillerb Are the included files accessible from the container, though?

Not natively, they'd need to be copied into the container.

I think I had a look at the time to see if there was a COPY for the .gitconfig but couldn't find how the logic was derived between global, repo config copy.

[sanmai-NL]

Please do not copy this kind of stuff, you may end up baking an image with sensitive information inside it.

I use this in devcontainer.json:

{
    "mounts": ["source=${localEnv:HOME}${localEnv:USERPROFILE}/.config/git,target=/root/.config/git,type=bind,consistency=cached,readonly"],
}

The includeIf directive works if you control where you mount your project inside the container. If you emulate the full path, it should work. However, this kind of config is developer-specific, and you wouldn't want to change devcontainer.json with such details. So instead I just configure those few settings you list there as working copy-local settings (git config ....).

[brettmillerb]

Please do not copy this kind of stuff, you may end up baking an image with sensitive information inside it.

I use this in devcontainer.json:

{
    "mounts": ["source=${localEnv:HOME}${localEnv:USERPROFILE}/.config/git,target=/root/.config/git,type=bind,consistency=cached,readonly"],
}

If I have to remember to set a mount in the devcontainer.json then it kind of negates the reasons I'm using includeif in the first place and I'd be better setting repo specific settings

The includeIf directive works if you control where you mount your project inside the container. If you emulate the full path, it should work. However, this kind of config is developer-specific, and you wouldn't want to change devcontainer.json with such details.

I generally only use local docker containers for developing projects rather than using SSH etc

So instead I just configure those few settings you list there as working copy-local settings (git config ....).

Not sure what you mean by copy-local settings?

I mainly use includeif so I don't forget to set my user and email config on repos so if the only option was to set something on a per repo basis e.g. devcontainer.json then I'll just stick to using git cli in an external terminal rather than the vscode integrations.

Appreciate this isn't everyone's usecase buts it's definitely a limitation

[sanmai-NL]

Please do not copy this kind of stuff, you may end up baking an image with sensitive information inside it.
I use this in devcontainer.json:

{
    "mounts": ["source=${localEnv:HOME}${localEnv:USERPROFILE}/.config/git,target=/root/.config/git,type=bind,consistency=cached,readonly"],
}

If I have to remember to set a mount in the devcontainer.json then it kind of negates the reasons I'm using includeif in the first place and I'd be better setting repo specific settings

I don't think so. Since you would have to reconfigure your per-repo settings on every clone, rather than once upstream per repo (and only for repos that should support both VS code dev containers and conditional Git config).

The includeIf directive works if you control where you mount your project inside the container. If you emulate the full path, it should work. However, this kind of config is developer-specific, and you wouldn't want to change devcontainer.json with such details.

I generally only use local docker containers for developing projects rather than using SSH etc

So instead I just configure those few settings you list there as working copy-local settings (git config ....).

Not sure what you mean by copy-local settings?

What you called repo specific settings.

I mainly use includeif so I don't forget to set my user and email config on repos so if the only option was to set something on a per repo basis e.g. devcontainer.json then I'll just stick to using git cli in an external terminal rather than the vscode integrations.

Appreciate this isn't everyone's usecase buts it's definitely a limitation

A bit more integrated would be to use a local terminal in a second Visual Studio Code window.

[sanmai-NL]

My robust, standard solution for this is to alter the conditional to only require a subdirectory that marks it as a Git hosting service/instance, instead of forcing it the be under the home directory.

~/.git/config

[user]
useConfigOnly = true

[includeIf "gitdir/i:devel/github/"]
path = github.gitconfig

I think VS Code should not apply additional logic to fix up path references in the Git config, and I believe this issue can be closed based on e.g. my solution. @brettmillerb, can you confirm to @chrmarti?

[brettmillerb]

@sanmai-NL I've just ended up not using the git functionality inside of vscode and use local terminal to interact with git.

I can try and test this at some point to see if it's a better workflow.

[DC4JG]

I'm currently stuck on this very issue.

I want to use the VSCode devcontainer support to offer developers a comfortable way of setting up the environment., extensions, etc. after they cloned the repository.

It works for trivial single user git configs but if an advanced multi user git config is encountered with usage of includeIf the whole git support inside the container breaks due to VSCode ignoring those other conditional include files, resulting in an incomplete git configuration.

The whole problem and missing support seems to be rooted even deeper than VSCode itself, since there is no way to export the currently active git configuration of a directory. git config --list shows the currently active settings but drops the ini file format, hence can't be used without extensive custom parsing to restore a valid gitconfig file.

This leaves the following options, all not desirable:

• Force all developers to not use conditional git configs
• Drop in-container git support and fall back to e.g. a parallel second non-containered VSCode instance for git usage
• Extensive custom scripting to create valid local repository git configs prior to container invocation

Is there any less annoying solution or workaround available for this issue? 🤔

[chrmarti]

You could use a dotfiles repository to bring in your own .gitconfig and files to include.

[sanmai-NL]

@DC4JG What doesn't work for you about the solution I outlined?

[DC4JG]

@sanmai-NL I tried your conditional include without the explicit home path for the repository and config file but it made no difference for me. It still won't copy/set the included gitconfig file into the devcontainer. I don't have a path issue inside the container but that container creation not respects/fixes the active includes and breaks the config once inside it.
Maybe I'm missing your point, could you elaborate?

Rough explanation of my test setup:

~/
  .gitconfig // includes foo.config if in ~/foo
  foo.config // sets user name/email

~/foo/
  .git/ // normal git init
  .devcontainer/ // container setup

It takes ~/.gitconfig and ~/foo/.git/config into consideration for the container but the included foo.config is ignored.

It successfully sets the conditionals when checked in the foo folder in WSL2 via git config --list --show-origin but when I reopen the container there is only the include statement from the global git config left, missing the other file's configuration.

---

My goal is to not force any specific setup or required configurations upon the container user but if possible just take whatever they configured for git and is actually active/valid in the folder of the repository like foo from above example and shift it over to the container to be seamlessly integrated into normal OS/tooling/VSCode(Extensions)/Git/SSH/GPG... setup. Below my targeted workflow.

• setup (advanced) git credentials and SSH key for access
• git clone repository (with .devcontainer folder)
• (open folder in VSCode if not already used for cloning)
• click notification to reopen in container
• (wait for Docker...) have a full IDE setup available and ready to work

This would greatly unify the developer environments, make onboarding much easier, keep the native operating system clutter free, enable easy unification of e.g. formatter, linting and other extensions configs and many other things which normally tend to cost a lot of time and effort to setup and slightly differ afterwards between people like person A installed X then Y but person B installed Y before X. If this whole process is encapsulated once, it can even be moved to remote servers/cloud if local machine resources become a limiting factor in the future.

---

We choose to go to the DevContainer in this setup and do the other things, not because they are easy, but because they are hard, because that goal will serve the organization and measure the best of our engineering and developer skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone, and one which we intend to win, and the management, too.