Override Git's User Email by Folder

Sun, 03 Mar 2024 15:19:19 -0500

Never forget to set your work email after cloning a work Git repository again!

When using a single computer for multiple categories of development (personal, work, etc), there is often a need to set a specific user.email value for each repository cloned depending on the use. For example, it’d make sense to use your work email for repositories cloned for work while you’d use your personal email for you own projects.

Without the following setup, it’s very easy to forget to override your user.email at a repository level and end up committing to one or the other with the wrong email attached. Though not the end of the world, I can imagine your company, coworkers, and security department would prefer to see your work email attached to all commits instead of a random Gmail account.

With the following in place, you’ll never forget to have the correct user.email set again!

Note: The following only works if you split up your repository clones within dedicated folders…which is probably better than mixing professional and personal repository together anyways.

.
├── personal
│   ├── repo1
│   └── repo2
└── work
    ├── repo1
    └── repo2

In your main ~/.gitconfig:

; Set your desired default name and email
[user]
    name = Bob Loblaw
    email = bob@home.com

; Override your user info, and anything else, depending on the folder you're
; currently in
; It's important this comes after anything you're overriding
[includeIf "gitdir:~/Development/work/**"]
    path = ~/.gitconfig_work.inc

Now in ~/.gitconfig_work.inc you can set your work specific information

1
2
3

[user]
    name = Bob Loblaw
    email = bob@work.com

With those configs, now any Git interaction within ~/Development/work/** will be done with user.email set to bob@work.com. No need for any local Git config overrides ever again to set common settings for work vs personal repositories.

A Git Alias for Keeping a Tidy Development Environment

Sun, 25 Feb 2024 22:07:36 -0500

Over time, whether working alone or in a team, your Git environment can become cluttered and messy with branches of the past, both local and remote. Though this isn’t an issue in the short term, if left alone, it can lead to time wasting mistakes, out of date code that doesn’t work once pushed to origin, and clutter in any Git tools or GUIs you may use leading to lower productivity.

How many local and remote branches do you see in one of your projects when you run git branch -a?

The following alias in your ~/.gitconfig will not only become second nature to use when updating your base branch, but it’ll keep your environment tidy at the same time.

[alias]
    update-main = !git checkout main \
        && git pull \
        && git remote prune origin \
        && git branch --merged | grep -v "\\\\*" | xargs -n 1 git branch -d

Now any time you want to begin work on a new branch, first run git update-main to not only update your main branch but also tidy your development environment. Then checkout your new branch and get to work.

It doesn’t really add any time to the process, has a lot of benefits by negating the problems below, and eventually becomes second nature to use any time you move over to a base branch.

Note: If your base branch is different, such as master or develop, add another instance of this alias with the proper replacements. Personally, I have 3 instances covering main, master, and staging which are often used in teams I’ve been on.

Once setup, they rarely change or need to be thought of again. I’ve been using these since around 2013 and I’ve rarely given them a second thought other than to share them with others.

Common Problems with a Messy Environment

Out of Date Base Branch

How often have you completed work on a new feature and pushed your code to Github only to find out your PR is already out of date? How?! It’s a brand new PR!

Well, it turns out locally you forgot to update your base branch (main) before checking out a new branch to start work on your new feature. There’s a high chance of this happening if you’re working within a team and commits are landing in the base branch frequently.

Though this is relatively inconsequential most of the time, the worst case would be that your code doesn’t work with the latest of the base branch at all! Though this would hopefully be very rare, it’s also easily avoided by keeping your environment tidy.

Git Clutter == Cognitive Load & Lower Productivity

Only slightly hyperbolic, a messy Git environment does decrease your overall productivity by making the tools you use to interact with Git slower to use. Whether it’s tab completion or GUIs visualizing branches, keeping a lot of stale or merged branches around adds no value and only presents downsides.

Alias Breakdown

Let’s go through some key points of some of the lines below for clarity and understanding.

[alias]
    update-main = !git checkout main \
        && git pull \
        && git remote prune origin \
        && git branch --merged | grep -v "\\\\*" | xargs -n 1 git branch -d

Running Shell Commands with `!`

By default every alias is expected to be a Git command. If you want to call git itself, you need to prefix the call with ! to indicate it should be calling a shell command instead of a Git command. So !git checkout main at the start of the alias will ensure it and the rest of the commands run as shell commands. No more git: 'git' is not a git command. errors.

Pruning Remote Branches

Over time branches will often be deleted from the remote origin during the natural development process. Your development environment however will not be kept up to date without either the right default configurations or manual calls as I’m using here. git remote prune origin will just ensure that any deleted remote branches are cleared from your development environment as well.

Note: Everything in this process works best if you delete remote branches after they’re merged. Though not fully required, there is no benefit to keeping merged remote branches around.

Pruning Merged Local Branches

`1`	`git branch --merged \| grep -v "\\\\*" \| xargs -n 1 git branch -d`

This is an interesting line in that it’s listing out all local branches that have no changes from the current branch and then deletes them. grep -v "\\\\*" is filtering out the current branch from the output of git branch --merged so that any other lines can be fed to the delete command.

This works best when run from the base branch you’re updating (main) so using it within this alias is recommended. There’s no harm if it removes the local instance of main however, as it will just be re-checked out from remote the next time you need it.

I hope this alias, and some of the backing information, is useful to your every day development. There’s always something new and shiny in the world of software but I always find it interesting to reflect on those little things set up over a decade ago that are still used dozens of times per day and now couldn’t be lived without.

Progress & productivity doesn’t always have to be a search for a new tool or dependency, sometimes it’s just stitching together various commands into an alias that fits your flow, reduces mistakes, and makes your environment more enjoyable to work in.

Productivity on Grant Lucas