Introducing Gitconfig Provider

Everyone is working with Git as their source providers nowadays. Your organization is hosting your code in private Git Servers like Bitbucket, GitLab or Private Git Repos hosted on github. If they work on opensource tools, they may host them in Github. Also you’re using a user for your open-source github contributions or some demo or writing a blog like this one.

The account which commits in private work related repos, and account which commits to your opensource github are most likely different users, two different git identities, and switching from one identity to other based on the remote repository is not that straightforward. And most of the times, your commit history will end up like this.

Like me, if you have faced any issue when switching between personal and work identities in git. I have created a tool that will help us solving the problem, automatically.

Introducing Gitconfig Provider

To help between switching different git identities, I have created a CLI tool that should run in your git repository. That CLI tool will read your git remotes, apply any config values you add to specific provider before the command runs.

By default this CLI covers 3 git service providers, Github, bitbucket and Gitlab, and on top of that, you can add any provider as long as you have their git remote url handy while adding. Once you add the provider, you can add configs for that provider like user.email and user.name and any other configuration you like.

Once you are done adding the config, when you run apply command, this CLI will fetch your remote repository url, finds origin repository and apply configuration for that remote. If the CLI doesn’t find any remotes with origin, it will pick the first remote from the list to check for any configs.

If you want to try the CLI, head over to Releases section of the repository and download CLI that runs on your OS.

You can see all available commands from the readme here, or you can run gitconfig-provider --help command to see all available options.

Technical Details and some Knowhow.

As I said earlier I am interested in Go. Prior to writing this CLI, I have prepared some simple CLI helper scripts and I am impressed what Go can do in that space. And that’s why I have decided to develop this CLI in Go.

When I was studying Go with help of Gophercieses, I came to know about Cobra which adds more functionality over Go’s default CLI functionality, e.g. Creating help pages automatically, Creating Subcommands and creating and managing flags properly. So I have decided to use Cobra for managing subcommands and flag.

This CLI works like this. All the configurations and providers are stored in the home directory of user’s computer in a json file. All the commands are read from or written to the same json file, which is managed by a centralized go file called data.go.

Whenever a subcommand runs for first time, the file reads that json file for any existing data stored in the file. If nothing is found, which is the case when this CLI runs for first time in your machine, we will write 3 default providers along with their URLs. You can see all these from this Code

The Git Commands and configuration

Everything in Git is done via some commands. Appliying identities is no exception. If we are to do it manually we use git config {configName} {configValue} command and that configuration is applied locally to our project. If there is no local configuration applied, git tries to fetch same config from global configuration file and applies it to your repository. You can add global configuration using --global flag in git config command. Thus git config --global {configName} {configValue} will apply same config Globally for your machine.

Every commit must have user.name and user.email property attached to it. Without that git won’t let you commit anything. Ideally this is stored globally in your machines, or this is stored locally using command line or in .gitconfig file.

Usually to have different identities, you should run gitconfig-provider addConfig -provider={ProviderName} -key=user.name -value={YourProviderUserName}.

For Example in github you should fire below commands to add your identity for github.

gitconfig-provider addConfig -provider=Github -key=user.name -value={YourGithubUserName}

And

gitconfig-provider addConfig -provider=Github -key=user.email -value={EmailYouUseForGithubCommits}.

To confirm this setup, when you run gitconfig-provider listProviders you can see your github user name and email loaded with the value you have provided with abive commands.

Releasing the Binaries using GoReleaser

I like the way that all the output of Go is standalone executable binaries that can run directly in a host machine without any external runtime or library installed. GoReleaser is a tool that automates and simplifies lot of your deployment processes, especially when we are doing some OS Specific stuffs like running commands in Shell/Bash (in Unix like systems) of Cmd in windows. (Like this).

By default when we run go build command, Go will create binaries for OS and architecture in machine the command is run. E.g. If you’re running in 64bit Linux machine, go build will create a binary that can run on 64 bit Linux machine, not for windows or Mac. If you want to create a binary for all the OS and Architectures, you need to pass necessary flags while creating binaries. Like GOOS=windows GOARCH=386 go build -o ... or GOOS=darwin GOARCH=amd64 go build -o ... to build for Windows x86 machines or 64bit mac machines. Doing this manually is tedious process. And GoReleaser makes this and other tasks far more easier.

GoReleaser reads a configuration file called .goreleaser.yml. We can use this configuration file to list out all the OS and Architecture, apart from that we can configure any commands to run as build hooks, or how to manage the output and changelog. GoReleaser also provides Github Action that will create a Github Release everytime we push any tags. You can read more about GoReleaser here.

You can download latest gitconfig-provider releases from here. Play with it and let me know what you think about this CLI. If you find any issues, feel free to create an issue here or feel free to add any discussions here.

Future

This is not it for gitconfig-provider. The CLI lacks cloud storage where users can backup their settings centrally from any machine and can restore it to any machine. The codebase also requires some refactoring and testing needs to be added before that. I will write posts about them when their time comes, till then.

May the force be with you…