Update git config recursively

Git is the must-have tool for almost all IT positions. No matter if you’re Developer, Release Engineer or maybe classy SysOp, you arguably have to use git (or any other Source Control tool). I use git, so I can tell you have I solved my problem with working with multiple git configurations. You know, when you work only for one company, it’s not a big deal – especially when you have business devices. One configuration, one account, and no problems. But the situation changes once you need to work for multiple companies and you are a part of multiple teams or any other group on GitHub, Bitbucket, GitLab and so on. Then maybe you need to update your git config recursively.

If you have your own accounts, with your e-mail address, one username, then your situation is much simpler than those guys, who have to use the company’s accounts. Then you are forced to use multiple e-mails in configurations, maybe multiple usernames and other settings. You can change git config for each repository, but it can be very… annoying. You can do that in a simpler way. To be honest – in a few ways.

Why do I want to update git config recursively?

Updating manually each repository is the way, that no one wants to follow. The human memory is fallible, so you can make a mistake very easily. So one of the best solutions could be recursively updating the git config. Most people have all the stuff related to one company in a separate directory, so why can’t we use that to set configuration recursively? Let’s consider the following structure:

As you can see, we have two companies and different repositories. And now we can do something, that results in configuration inheritance. Each repository under CompanyA directory will inherit a set of configurations specific to this CompanyA, and CompanyB will inherit a set of configurations specific to this CompanyB. So we will be able to update git config recursively. And not only the git config!

So how can I update git config recursively?

I know two ways how I can achieve that goal.

  1. Use includeIf section in ~/.gitconfig file to include other git configs.
  2. Use direnv to load GIT_CONFIG variable with value dependent on the directory.

I want includeIf, new packages are passé!

Details of includeIf usage are described in the official git repository, here. The only requirement you have to meet is the version of git – 2.13. If you have this version, then you can use this section to create multiple git identities stored in separate files. Let use the example above with two different Companies directories. Create the following files in your home directory (as the main git config file is stored in ${HOME}/.gitconfig, so it would be great to have the rest of the files in the same place):

  • .gituser-default
  • .gituser-companya
  • .gituser-companyb

And put into them different users and e-mail:

Now in ${HOME}/.gitconfig add necessary configuration:

From now, when you initialize git, you can update your git config recursively thanks to that trick. Only with the git functionalities!

What if I want more and I accept new packages?

Then you can use direnv to extend your shell possibilities. Direnv is a small open-source project written in go lang, that allows loading environment variables based on the directory. Of course, it knows how to inheritance. So you can not only update git config recursively but also use this tool to load specific variables for specific projects, application environments and so on.

Git can adjust the file with configuration with the environment variable GIT_CONFIG. So we can use direnv to load different values with different configurations depending on the directory. But first, we need to install this tool you can check how to do that in the official documentation:

Please remember about hook direnv into your shell section! It won’t work without that step!

It’s a very simple extension, so it shouldn’t be hard to learn how to use that. Once you have that installed, you can create two files in the top of the companies’ directories:

The .envrc files are used by direnv to read environment variables from them and use them in the current shell session. But before we touch them, let’s add necessary configuration in the gitconfig files (as you see, now we use just .gitconfig names, and we store them in the company’s directory. Thanks to that, we have everything related to our work in one place):

Now we can move to the .envrc files. In each of them, you need to export the same GIT_CONFIG variable, but with different values.

Thanks to that, we can (if we need) store even our configuration in the git repository, so it’s possible to restore that on absolutely any new machine!

Anyway, when we’re done, we can check if it works. To do that, go to any repository inside any of the companies’ directories and see what happens. You should see something similar to this:

And voila! Now you can update git config recursively without manual work!

Any problem?

⚠️NOTE! ⚠️If you see the following warning:

it means, that you’ve not approved direnv in that directory yet. It’s a security mechanism that allows controlling the directories, where direnv can be used to avoid any unnecessary variables loading.

Useful links

  1. Main page of direnv project
  2. Github repository of direnv project
  3. Git documentation with includeIf section

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.