This chapter is a collection of short but useful tricks to make our Git experience more comfortable. In the first three chapters, we learnt all the concepts we need to take the first steps into versioning systems using the Git tool; now it's time to go a little bit more in depth to discover some other powerful weapons in the Git arsenal and see how to use them (without shooting yourself in your foot, preferably).
In the first part of this chapter, we will learn how to enhance our Git configuration to better fit our needs and speed up the daily work; now it's time to become familiar with the configuration internals.
The configuration options are stored in plain text files. The git config command is just a convenient tool to edit these files without the hassle of remembering where they are stored and opening them in a text editor.
In Git we have three configuration levels which are:
- System
- User
- Repository
There are different configuration files for every different configuration level.
You can basically set every parameter at every level according to your needs. If you set the same parameters at different levels, the lowest-level parameter hides the top level parameters; so, for example, if you set user.name at global level, it will hide the one eventually set up at system level; if you set it at repository level, it will hide the one specified at global level and the one eventually set up at system level.
The system level contains system-wide configurations; if you edit the configuration at this level, every user and its repository will be affected.
This configuration is stored in the gitconfig file usually located in:
- Windows -
C:Program Files (x86)Gitetcgitconfig - Linux -
/etc/gitconfig - Mac OS X -
/usr/local/git/etc/gitconfig
To edit the parameters at this level, you have to use the --system option; please note that it requires administrative privileges (for example, root permission on Linux and Mac OS X). Anyway, as a rule of thumb, the edit configuration at system level is discouraged in favor of per user configuration modification.
The global level contains user-wide configurations; if you edit the configuration at this level, every user's repository will be affected.
This configuration is stored in the .gitconfig file usually located in:
- Windows -
C:Users<UserName>.gitconfig - Linux -
~/.gitconfig - Mac OS X -
~/.gitconfig
To edit the parameters at this level, you have to use the --global option.
The repository level contains repository only configurations; if you edit the configuration at this level, only the repository in use will be affected.
This configuration is stored in the config file located in the .git repository subfolder:
- Windows -
C:<MyRepoFolder>.gitconfig - Linux -
~/<MyRepoFolder>/.git/config - Mac OS X -
~/<MyRepoFolder>/.git/config
To edit parameters at this level, you can use the --local option or simply avoid using any option as this is the default one.
To get a list of all configurations currently in use, you can run the git config --list option; if you are inside a repository, it will show all the configurations from repository to system level. To filter the list, append --system, --global, or --local options to obtain only the desired level configurations, as shown in the following screenshot:
Even if it is generally discouraged, you can modify Git configurations by directly editing the files. Git configuration files are quite easy to understand, so when you look on the Internet for a particular configuration you want to set, it is not unusual to find just the right corresponding text lines; the only little foresight to maintain in those cases is that you always need to back up files before editing them. In the next paragraphs, we will try to make some changes in this manner.
Using Git can be a painful experience if you are not able to place it conveniently inside your work environment. Let's start to shape some rough edges using a bunch of custom configurations.
In the previous chapters, we saw that we can change a Git variable value using the git config command with the <variable.name> <value> syntax. In this paragraph, we will make use of the config command to vary some Git behaviors.
So, let's try to fix an annoying question about the typing command named
typos. I often find myself re-typing the same command two or more times; Git can help us with embedded autocorrection, but we first have to enable it. To enable it, you have to modify the help.autocorrection parameter, defining how many tenths of a second Git will wait before running the assumed command; so by giving a help.autocorrect 10 command, Git will wait for a second, as shown in the following screenshot:
To abort the autocorrection, simply type Ctrl + C.
Now that you know about configuration files, you can note that the parameters we set by the command line are in this form: section.parameter_name. You can see the sections' names within [] if you look in the configuration file; for example, you can find them in C:Users<UserName>.gitconfig, as shown in the following screenshot:
We already talked about the git push command and its default behavior. To avoid such annoying issues, it is a good practice to set a more convenient default behavior for this command.
There are two ways we can do this. The first one is to set Git to ask to us the name of the branch we want to push every time, so a simple git push will have no effects. To obtain this, set push.default to nothing, as shown in the following screenshot:
As you can see, now Git pretends that you specify the target branch at every push.
This may be too restrictive, but at least you can avoid common mistakes like pushing some personal local branches to the remote, generating confusion in the team.
Another way to save yourself from this kind of mistake is to set the push.default parameter to simple, allowing Git to push only when there is a remote branch with the same name as that of the local one, as shown in the following screenshot:
This action will push the local tracked branch to the remote.
Some people really don't like vim, even only for writing commit messages; if you are one of those people, there is good news for you in that you can change it instead by setting the core.default config parameter:
$ git config --global core.editor notepad
Obviously you can set all text editors on the market. If you are a Windows user, remember that the full path of the editor has to be in the PATH environment variable; basically, if you can run your preferred editor typing its executable name in a DOS shell, you can use it even in a Bash shell with Git.
You can browse a wide list of other configuration variables at http://git-scm.com/docs/git-config.