There are configuration targets in the core Git system. In this section, we'll take a closer look at a few of them that might be useful in your daily work.
We'll look at the following three different configuration areas:
- Rebase and merge setup
- Expiry of objects
- Autocorrect
In this exercise, we'll just set a few configurations. We'll use the data model repository from Chapter 1, Navigating Git:
$ cd data-model
Let's take a closer look at the previously mentioned configuration areas.
By default, when performing git pull, a merge commit will be created if the history of the local branch has diverged from the remote one. However, to avoid all these merge commits, a repository can be configured so it will default to rebase instead of merging when doing git pull. Several configuration targets related to the option exist as follows:
pull.rebase: This configuration, when set totrue, will pull to rebase the current branch on top of the fetched one when performing agit pull. It can also be set topreserveso that the local merge commit will not be flattened in the rebase, by passing--preserve-mergestogit rebase. The default value isfalseas the configuration is not set. To set this option in your local repository, run the following command:$ git config pull.rebase truebranch.autosetuprebase: When this configuration is set toalways, any new branch created with<git branchorgit checkoutthat tracks another branch will be set up to pull to rebase (instead of merge). The valid options are as follows:never: This is set to pull to rebase (default)local: This is set to pull to rebase for local tracked branchesremote: This is set to pull to rebase for remote tracked branchesalways: This is set to pull to rebase for all tracked branches
To set this option for all the new branches regardless of tracking remote or local branches, run the following command:
$ git config branch.autosetuprebase alwaysbranch.<name>.rebase: This configuration, when set totrue, applies only to the<name>branch and tells Git to pull to rebase when performinggit pullon the given branch. It can also be set topreserveso that the local merge commit will not be flattened when runninggit pull. By default, the configuration is not set for any branch. To set thefeature/2branch in the repository to default to rebase instead of merge, we can run the following command:$ git config branch.feature/2.rebase true
By default, Git will perform garbage collection on unreferenced objects and clean reflog for entries, both of which are older than 90 days. For an object to be referenced, something must point to it; a tree, a commit, a tag, a branch, or some of the internal Git bookkeeping like stash or reflog. There are three settings that can be used to change this time as follows:
gc.reflogexpire: This is the general setting to know for how long a branch's history is kept inreflog. The default time is 90 days. The setting is a length of time, for example,10 days, 6 monthsand it can be turned completely off with the valuenever. The setting can be set to match arefspattern by supplying the pattern in the configuration setting.gc.<pattern>.reflogexpire: This pattern can, for example, be/refs/remotes/*and the expire setting would then only apply for those refs.gc.reflogexpireunreachable: This setting controls how long thereflogentries that are not a part of the current branch history should be available in the repository. The default value is30 days, and similar to the previous option, it is expressed as a length of time or set toneverin order to turn it off. This setting can, as the previous one, be set to match arefspattern.gc.pruneexpire: This option tellsgit gcto prune objects older than the value. The default is2.weeks.ago, and the value can be expressed as a relative date like3.months.ago. To disable the grace period, the valuenowcan be used. To set a non-default expiry date only on remote branches, use the following command:$ git config gc./refs/remote/*.reflogexpire never $ git config gc./refs/remote/*.reflogexpireunreachable "2 months"
We can also set a date so
git gcwill prune objects sooner:$ git config gc.pruneexpire 3.days.ago
This configuration is useful when you get tired of messages like the following one just because you made a typo on the keyboard:
$ git statis git: 'statis' is not a git command. See 'git --help'. Did you mean this? status
By setting the configuration to help.autocorrect, you can control how Git will behave when you accidentally send a typo to it. By default, the value is 0 and it means to list the possible options similar to the input (if statis is given status will be shown). A negative value means to immediately execute the corresponding command. A positive value means to wait the given number of deciseconds (0.1 sec) before running the command, (so there is some amount of time to cancel it). If several commands can be deduced from the text entered, nothing will happen. Setting the value to half a second gives you some time to cancel a wrong command, as follows:
$ git config help.autocorrect 5 $ git statis WARNING: You called a Git command named 'statis', which does not exist. Continuing under the assumption that you meant 'status' in 0.5 seconds automatically... # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: another-file.txt #
Setting the configuration targets will change the way Git behaves. The previous examples describe a few useful methods to get Git to act differently than its default behavior. You should be sure when you are changing a configuration that you completely understand what that configuration does. So, check the Git configuration help page by using git help config.