In this document, we’re going to take an in-depth look at the git config command. We briefly discuss using git config on our Configuring a Repository page. The git config command is a convenience function used to set Git configuration settings at a global or local project level. These configuration levels correspond to .gitconfig text files. Running git config will modify a configuration text file. We’ll cover common configuration settings like email, username, and editor. We’ll discuss Git aliases, which allow you to create shortcuts for frequently used Git operations. Familiarizing yourself with git config and the various Git configuration settings will help you create a powerful and customized Git workflow.
Usage
The most basic use case for git config is to invoke it with a configuration name, which will display the value set to that name. Configuration names are dot-delimited strings composed of a ‘section’ and a ‘key’ based on their hierarchy. For example:
user.email git config user.email
In this example, email is a child property of the user configuration block. This will return the configured email address, if any, that Git will associate with locally created commits.
git configuration
levels and files
Before we further discuss the use of git configuration, let’s take a moment to cover configuration levels. The git config command can accept arguments to specify at which configuration level to operate. The following configuration levels are available:
- –
local
By default, git config will write to a local level if no configuration option is passed. Local-level settings are applied to the context repository in which git config is invoked. Local configuration settings are stored in a file that can be found in the repository’s .git directory: .git/config
- –
global
Global-level settings are user-specific, meaning they apply to an operating system user. Global settings are stored in a file that is located in a user’s home directory. ~ /.gitconfig on Unix systems and C:\Users\\.gitconfig on Windows
–
- system System-level
settings are applied on an entire machine. This covers all users of an operating system and all repositories. The system-level configuration file resides in a gitconfig file outside the system root path. $(prefix)/etc/gitconfig on Unix systems. On Windows, this file can be found in C:\Documents and Settings\All Users\Application Data\Git\config in Windows XP and in C:\ProgramData\Git\config in Windows Vista and later.
Therefore, the order of priority for the configuration levels is: local, global, system. This means that when a configuration value is searched, Git will start at the local level and bubble up to the system level.
Writing
a value Expanding on what we already know about git config, let’s look at an example
where we write a value: git config
-global user.email “your_email@example.com”
This example writes the value your_email@example.com to the configuration name user.email. Use the -global flag for this value to be set for the current operating system user.
Git
Configuration Editor
–
core.editor Many Git commands will launch a text editor to request more input. One of the most common use cases for git config is to configure which editor Git should use. Below is a table of popular editors and
matching git configuration commands: Atom editor configuration command ~ git config -global core.editor “atom -wait”~ emacs ~ git config -global core.editor “emacs”~ nano ~ git config -global core.editor “nano -w”~ vim ~ git config -global core.editor “vim”~ Sublime Text (Mac) ~ git config -global core.editor “subl -n -w”~ Sublime Text (Win, 32-bit installation) ~ git config -global core.editor “‘c:/program files (x86)/sublime text 3/sublimetext.exe’ -w”~ Sublime Text (Win, 64-bit installation) ~ git config -global core.editor “‘c:/program files/sublime text 3/sublimetext.exe’ -w”~ Textmate ~ git config -global core.editor “mate -w”~
Merge tools
In case of merge conflict, Git will launch a “
merge tool.” By default, Git uses an internal implementation of the Unix common diff program. The internal Git diff is a minimal merge conflict viewer. There are many external third-party combination conflict resolutions that can be used instead. For an overview of various merge and configuration tools, see our guide on tips and tools for resolving conflicts with Git.
git config -global merge.tool kdiff3
Colored outputs
Git supports
colored terminal output that helps to quickly read Git output. You can customize your Git output to use a custom color theme. The git config command is used to set these color values.
color.ui
This is the master variable for Git colors. Setting it to false will disable all colored terminal output from Git’.
$ git config -global color.ui false
By default, color.ui is set to auto which will apply colors to the immediate terminal output stream. Auto configuration will skip color-code output if the output stream is redirected to a file or piped to another process.
You can set the color.ui value to always, which will also apply the output of the color code when redirecting the output stream to files or pipes. This can cause problems unintentionally, as the receiving pipe may not be waiting for a color-coded inlet.
Git
color values
In addition to color.ui, there are many other granular color settings. Like color.ui, all of these color settings can be set to false, automatic, or always. These color adjustments can also have a specific color value set. Some examples of supported color values are:
- normal
- black red
- green
- yellow
- blue
- magenta
- cyan
- white
Colors can also be specified as hexadecimal color codes such as #ff0000, or ANSI 256 color values if your terminal supports it
. Git color settings 1. color.branch
- Sets the output color of the Git 2 branch command
.
color.branch.
<slot>
- This value also applies to the output of the Git branch. <slot> is one of the following: 1. current: the current branch 2. local: a local branch 3. remote: a remote branch reference
- in refs/remotes
- 4. Upstream: an upstream branch branch
- 5. Plain: any other reference 3.
- color.diff
Applies colors to git diff, git
- log, and git show output
4. color.diff.<slot> Setting a <slot> value in color.diff tells git where in the patch to use a
- specific color. 1. context: The context text of
- the diff. The Git context is the lines of text content displayed in a diff or patch that highlights changes
- 2. Plain: synonymous with context 3.
- to the meta information in diff
- function in hunk header”
- 5. Old: Applies
- 6. New: Colors the added lines of
- 7. commit: Colors confirm headers within
- any white space errors in a diff
.
Meta: Applies color
4. Frag: Applies color to “Hunk header” or “
a color to the deleted lines at diff
diff
diff 8. White space: Sets a color for
5. color.decorate.
<slot>
- Customize the color for the git log -decorate output. The <slot> values supported are: branch, remoteBranch, tag, stash, or HEAD. They are respectively applicable to local branches, remote tracking branches, tags, hidden changes and HEAD.
6. color.grep
- Applies color to git grep output.
7. color.grep.
<slot>
- Also applicable to git grep. The <slot> variable specifies which part of the grep output to apply color. 1. Context: mismatched text in context lines 2. File Name: 3 filename prefix. Function: Function name lines 4. Line number: Line number 5 prefix. Match: matching text 6. matchContext: Matching text on context lines 7. matchSelected: matching text on selected lines
- 8. Selected:
- mismatched
- text
- selected lines
- 9. separator: separators between fields on a line (:, -, and =) and between chunks (-)
on
8. color.interactive This variable applies color for indications and interactive displays
- . Examples include git add -interactive and git clean -interactive
9. color.interactive.<
slot>
- The <slot> variable can be specified to point to the more specific “interactive output”. The available <slot> values are: prompt, header, help, error; and each act on the corresponding interactive output.
10
. color.pager Enables or disables color output
- when pager is in use
11
. color.showBranch Enables or disables color output for the git show branch 12 command. color.status
- A Boolean value that enables or disables color output
for Git
13
state. color.status.<slot> Used to specify the custom color for
- specified git
state elements.
<
slot> supports the following values:
1. header
-
- Goes to the header text in the status area
- or updated Both destination files that are added but not committed 3. Modified target files that are modified but not added to the git 4 index. Uncrawled target files that are
-
- not crawled by
-
- Git
-
- Applies
- 6. nobranch
- The color of the “no branch” warning is displayed at
- 7. uncombined
- Color files that have
unmerged changes
2. added
5. branch
color to the current branch
Alias You
may be familiar with your operating system’s command-line alias concept; if not, they are custom shortcuts that define which command will expand to longer commands or Combined. Aliases save you the time and energy cost of typing frequently used commands. Git provides its own alias system. A common use case for Git aliases is to shorten the commit command. Git aliases are stored in Git configuration files. This means that you can use the git config command to configure aliases.
git config -global alias.ci commit
This example creates a ci alias for the git commit command. You can then invoke git commit by running git ci. Aliases can also reference other aliases to create powerful combos.
git config -global alias.amend ci -amend
This example creates an alias modification that composes the ci alias into a new alias that uses the -amend flag
.
Formatting and
whitespace
Git has several “white space” features that can be configured to highlight whitespace issues when using git diff. whitespace issues will be highlighted using the configured color color.diff.whitespace
The following features are enabled by default: Highlights orphaned white space at line ends Highlights space before tab
- space character that appears before a tab character when you indent a line Highlights
- blank lines inserted at the end of a file
A
The following features are disabled by default
- indent-with-non-tab highlights a line that is indented with spaces instead of tabs tab indentation highlights
- initial tab indent as error
- trailing-space is an abbreviation for blank-at-eol and blank-at-eof cr-at-eol
- highlights a carriage return at line
- endings tabwidth= defines how many character positions a tab stops. The default value is 8. Allowed values are 1-63
an
Summary
In this article, we cover the use of the git config command. We discuss how the command is a conviction method for editing raw git configuration files in the file system. Basic read and write operations for configuration options were examined. We take a look at common configuration patterns:
How
- to
- configure the Git editor
- override configuration levels
- defaults
- How to customize
How to
How to reset configuration
git colors
In general, git config is a helper tool that provides a shortcut for editing raw git configuration files on disk. We cover personal customization options in depth. Basic knowledge of git configuration options is a prerequisite for setting up a repository. Check out our guide there for a demo of the basics.
