1

I have found through this answer that Git 2.31 introduced the environment variable override system (GIT_CONFIG_KEY_x, GIT_CONFIG_VALUE_x) which is now documented here. This is a very useful feature to me.

My use-case has a process (ansible galaxy in this case) that is running git commands behind the scenes. I would like to override some of that git config only for that action, but I can't use git -c command line arg since I'm not running git directly.

Using the described env vars works perfectly for this use-case as long as I have git 2.31 or above. It works great on my workstation that has a newer version of git, but my production systems are running Ubuntu 20.04 (focal) currently. The Apt repos only host git version 2.25 so I can't get >= 2.33 without doing a custom install without Apt, which I would really like to avoid.

So my question to this community: Given my specific use-case, is there is any alternate way to override config without feeding it a whole config file with GIT_CONFIG=config.conf with a version of git < 2.31?

Side note: the git config item I'm specifically trying to override is "advice.detachedHead=false"

Rino Bino
  • 366
  • 3
  • 15
  • The new fancy stuff is specifically there to sidestep the fact that `git -c =` exposes stuff to other users on the same machine, but if you're just shutting off the detached head noise, that's hardly "sensitive data"... – torek Dec 21 '22 at 12:42
  • Thanks, but I never claimed it was "sensitive data" :) – Rino Bino Dec 21 '22 at 16:29
  • I know - but the point is, since it *isn't* sensitive, `-c` is the way to go. It is simple and it works and the only fault it has is that it can expose sensitive data, which isn't a fault here! (I see from your comment to ElpieKay that the issue might be that you can't control what Git command ansible runs - but note that ansible may also mess with environment variables.) – torek Dec 22 '22 at 13:37
  • Thanks, and yes, `-c` is the correct answer if running git directly. Which I'm not so unfortunately I think I'll just be living with the verbose logs until my fleet is updated to a new git version. Appreciate the input. I edited my original question to make this a bit more clear. – Rino Bino Jan 04 '23 at 00:00

1 Answers1

2

If you want to override one or more values from configuration files, use -c.

Pass a configuration parameter to the command. The value given will override values from configuration files. The is expected in the same format as listed by git config (subkeys separated by dots).

Note that omitting the = in git -c foo.bar ... is allowed and sets foo.bar to the boolean true value (just like [foo]bar would in a config file). Including the equals but with an empty value (like git -c foo.bar= ...) sets foo.bar to the empty string which git config --type=bool will convert to false.

Examples,

git -c advice.detachedHead=true switch foo

git -c user.name=Hello -c user.email=Hello@world.com commit -m "Hello World"
ElpieKay
  • 27,194
  • 6
  • 32
  • 53
  • Thank you. However, git is running as a sub-process of another process so I can't pass args to it directly. (Sorry if this wasn't totally clear, it's mentioned in the second block of text in my original post). If this is impossible to accomplish for my use-case, that is an acceptable answer and if you edit your post to state that it would be a viable accepted answer imo. – Rino Bino Dec 21 '22 at 16:33
  • @RinoBino In my experience, a sub-process method should support to accept a git command which includes options like `-c advice.detachedHead=true`. Taking Python for example, `subprocess.Popen(['git', '-c', 'advice.detachedHead=true', 'switch', 'foo'])` can work. – ElpieKay Dec 22 '22 at 01:51
  • At that point I would need to be forking/customizing ansible-galaxy source and that is not something that is worth doing (since galaxy is what's doing the git actions). Seems there is no viable way to accomplish exactly what I'm trying to do which I can accept as reality. Appreciate the input regardless! – Rino Bino Jan 03 '23 at 23:58