Some git config values are configured at the system, some at the user level and some in the repository. When invoking
$ git config --list
I'm getting a list of all definitions in all files. Overridden values will occur duplicated. How to get a list of the repository's effective values (I don't care about where they are configured)?
Show global git config settings But at runtime, only the value set locally is used. If you would like to delete or edit a Git config value manually with a text editor, you can find the Git config file locations through the Git config list command's –show-origin switch.
The git config command is a convenience function that is used to set Git configuration values on a global or local project level. These configuration levels correspond to . gitconfig text files. Executing git config will modify a configuration text file.
To see all of properties configured globally in Git, you can use the –list switch on the git config command. Adding the –show-origin switch will also tell you the global . gitconfig file's location.
The tricky part is this:
Overridden values will occur duplicated.
It's true that some items, e.g., user.name
and user.email
, will have a more-local value override a more-global value. For other items, though, all the settings apply. This is true for remote.*.fetch
values, for instance.
The actual treatment of any one item depends on the program that examines the setting. The git config
command does not know how a git xyzzy
command—which is not yet written (it's something you will write some time in the future)—intends to use all the xyzzy.*
settings. So it just shows all of them. Use --show-origin
to show which particular configuration file was the source of any one particular setting.
If you're interested in one particular value, use git config --get
:
git config --get core.editor
or:
git config --get-all remote.origin.fetch
The --get
variant shows the last setting, i.e., the most-local one, while the --get-all
variant shows all the settings. Which one to use depends, of course, on how the program you will run—which might be one already written, or might be one you're in the process of writing now or will write next year—actually uses that variable.
One could argue that git config
should understand all the "well known" variable names (core.editor
vs remote.*.fetch
for instance) and default to showing them appropriately under --list
. The Git authors tend to treat Git as a tool-set rather than a solution, though, so they are not very receptive to this line of argument.
You can write this smarter version of git config --list
yourself. Perhaps you can call it git xyzzy
. :-) OK, maybe git smart-config-list
. Your smarter listing command will run git config --show-origins --list
, then apply the "all or last" filtering rule based on its knowledge about all those variable names. As you write this command, think about Git's "tools vs solutions" philosophy, and that git config
is not that well designed since it acts as both plumbing (internal-usage tool) and porcelain (an end-user-facing command).
Make a bash function:
function foo(){
para=$@
for key in `git config --list ${para}| awk -F= '{print $1}' | sort -u`;do
echo $key=`git config ${para} --get $key`
done
}
foo
to get a list of the repository's effective values. foo --global
, foo --local
, foo --system
, foo -f somefile
or foo --blob someblob
are also supported.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With