feat: can pass additional environment variables to git commands

[stevearc]

This adds the ability to specify additional environment variables to the git commands by passing them into the config:

config = {
  git = {
    env = {
      GIT_CONFIG_NOSYSTEM = "1"
    }
  }
}

[lewis6991]

Why can't you just set vim.env.GIT_CONFIG_NOSYSTEM outside of the packer config?

[stevearc]

For my specific work situation, we have cloud servers that we spin up to do development. The system git config has some settings that point git at a local git mirror in that cloud, which causes git clone/fetch/pull operations to fail if the target repo is not in that git mirror (e.g. all of my neovim plugins). So I need to ignore the system config for packer and for other operations that hit non-work git repos.

Unfortunately, if I set GIT_CONFIG_NOSYSTEM generally, that means that all my git operations that do interact with the work repos will now fail. So I need some way to set GIT_CONFIG_NOSYSTEM for only the git operations performed on non-work repos. This seemed like the best way to do that.

[lewis6991]

Ok how about this as an alternative:

$HOME/bin/git_nosys:

#! /usr/bin/bash
export GIT_CONFIG_NOSYSTEM=1
exec git "$@"

export PATH=$HOME/bin:$PATH

config = {
  git = {
    cmd = 'git_nosys'
  }
}

[stevearc]

Yeah, that would work. To be honest I like it a lot less because I'm using this for a single init.lua file kickstart-like reference for other people at work. Right now you can just copy the file and it works (pointing at my fork for packer). With the script solution, I'll need to also install that script and mutate their PATH (or I guess put it somewhere I can reference it absolutely). I think the simplicity of setup is worth it to me to just maintain my packer fork for them.

If you don't want to merge this PR for any reason, that's fine! I definitely understand scope creep and growing maintenance burden. Feel free to close this out 🙂

[lewis6991]

To be honest I like it a lot less because I'm using this for a single init.lua

Have you considered bootstrapping this script and storing it in the users XDG_DATA_HOME? That'll allow you to keep it in a single file. I know it's more work but worth considering other maintaining a fork.

I think for now we will pass on this, however I do appreciate the use case here and think it's interesting and important.

Adding config for this niche case, when a good enough (though less ideal) work around exists doesn't quite justify adding this to the config for me. I'll let others chime in if they disagree.

We can keep this use case in mind, and If anyone has other reasons for a custom git env then that'll increase the argument for adding this.

Thanks for your understanding!