Git Configuration

From NovaOrdis Knowledge Base
Jump to navigation Jump to search

External

Internal

Overview

Git maintains configuration in a hierarchy of files.

System-wide configuration is maintained in /etc/gitconfig. This configuration applies to all users of the system and it is read and written by git config --system [...]

User-specific configuration is maintained in in ~/.gitconfig or ~/.config/git/config. This configuration applies to a specific user, and it is read and written by git config --global [...]

Repository specific configuration is maintained in .git/config and it read and written with git config --local [...]

If no option is specified, --local is the default.

If the same configuration element is specified in multiple locations, the most specific value becomes the effective value: a repository-level value takes precedence over a user-level values, which takes precedence over the corresponding system-level value. To obtain the effective value of a configuration element, execute:

git config --get <config-element>

A list of configuration elements is available in the Configuration Elements section.

The configuration files are not replicated during the git clone operation.

The configuration files are plain-text, so values can be set manually by editing the file and using the correct syntax. It’s generally easier to run the git config command, though.

Files

Environment Variables

Git Environment Variables

Configuration Elements

[core]

autocrlf

Configures Git behavior in respect to the end of line terminator (carriage return and line feed characters on Windows, linefeed character on Mac and Linux). Git can interact with the new line terminator(s) at two moments: when a file is added to an index and when the file is checked out on the local system. "core.autocrlf" has the following values:

  • true: converts the LF endings into CRLF when the code is checked out.
  • input: converts the CRLF endings into LF when the file is written into the index, but not in reverse on checkout.
  • false: does not interact with the new line characters.
git config --global core.autocrlf input

[push]

default

This setting affects the behavior of the Git client when the branches to push are not specified. It can have the following values:

  • "nothing". Push nothing.
  • "matching". git push with no argument will push all local branches to the ones with the same name on the remote. You don't need to establish any No special link between the local branch and the remote branch needs to be established. However, this makes it easy to accidentally push a branch you didn't intend to.
  • "upstream" (deprecated synonyms "tracking", "simple"). Push the current branch to the configured upstream branch, making no assumptions on name match. git push will push only the current branch to the one that git pull would pull from. This is a more intuitive behavior, which is why the default in Git 2.0 is getting changed to this. Recommended value is "simple" - it is safer. Older clients used to call this value "simple".
  • "current". Push the current branch to a branch of the same name, assuming that the current branch and its upstream branch have the same name. For more context on where this is relevant, see:
Publish a Local Branch in a Remote Repository

[user]

name

[user]
	name = Ovidiu Feodorov
	email = ovidiu@example.com

email

[user]
	name = Ovidiu Feodorov
	email = ovidiu@example.com

[url]

insteadOf

[url "git@github.com:someorg/somerepo"]
	insteadOf = https://github.com/someorg/somerepo

Any URL that starts with the insteadOf value will be rewritten to start with the url's base.

This configuration provided below is stronger than the configuration specified above, in that it rewrites all the repositories from the organization:

[url "git@github.com:someorg"]
	insteadOf = https://github.com/someorg

This feature allows people to specify any of the equivalent URLs and have Git automatically rewrite the URL to the best alternative for the particular user, even for a never-before-seen repository on the site. When more than one insteadOf strings match a given URL, the longest match is used.

Note that any protocol restrictions will be applied to the rewritten URL. If the rewrite changes the URL to use a custom protocol or remote helper, you may need to adjust the protocol.*.allow config to permit the request. In particular, protocols you expect to use for submodules must be set to always rather than the default of user.

This is how to configure [url] in command line.

Configuration Operations

git config Configuration Operations