Recently while I was on GitHub I was asked to fill in a user survey. I only fill these in for sites I like and so I was happy to answer this one.

If you’ve been following this blog you know I launched a site to help people find GitHub repositories to contribute to. In the survey I mentioned I thought searching for repositories to contribute to could be enhanced.

There was a check box asking if I agreed to be contacted by GitHub. I checked it without really expecting anything to come out of it.

Well, a few days later I received an email with an invitation to a video chat with some friendly folks over at GitHub who wanted to know more.

It was a really nice experience, very friendly. The two people from GitHub (I don’t know if they want to be named so I’ll respect their privacy) were really attentive to what I had to say, more than I would have expected. I feel they really went the extra mile having checked out my GitHub profile, this blog, dispatcher and what I did for a living beforehand.

Hopefully my views on the matter helped them along in their own reflections on how to improve GitHub.

With these Git setup tips

Cut down on tedious credentials typing

When you start to push to remote repositories on a frequent basis, typing in you credentials can get tedious. For example, my GitHub user name is gilles-leblanc, which is fourteen characters and my password is around twenty characters. Combine this with two carriage return and that’s a whole lot of typing.

You can cut down on this tedious typing in two ways.

First you can store your username for a remote repository service like GitHub in your .gitconfig file. When this is done, Git will use this username and stop asking you for it altogether. I prefer not to store any passwords this way tough. This could be a security risk in case of accidental commit of the .gitconfig file or someone could get read access to the file.

Turn on the colours for more readability

Turning on the colours makes for a big change in readability, particularly when using git diff where you can scan for added and removed lines by colour.

git diff command with colour highlighting

Colouring is also applied on other commands like git log . You can turn on the colours either by using git config or by directly editing your .gitconfig file.

using the git config command

git config --global color.ui true

resulting .gitconfig file

[color]
ui = true

Setup Git to use your favourite editor

Git can be configured to use your favourite text editor. The standard text editor will vary depending on your OS, distribution and installation. Mine was nano. While using Git isn’t a text editor intensive operation, using a familiar editor is great for writing multi-line commit messages and rebase scripts where you have to change several pick commands.

You can configure this in your .gitconfig or in your shell’s configuration files. Here is an example of both (using Bash for the shell).

in the .gitconfig

[core]
editor = vim

in .bash_profile or .bashrc

export GIT_EDITOR=vim

Use Git and GitHub to store your Git dot files

You use Git and GitHub to track your source files, why not your dot files? Now that you have customised your settings, keep them safe in source control. Keeping your dot files in a Git repo will allow you to easily revert changes when something bad happens or just see when you changed a particular setting.

Hosting that Git repository on a service like GitHub (or BitBucket, Gitorius or others) will allow you to easily share and sync those files across different computers from anywhere.

I use a GitHub repository to store all my dot files. This is particularly useful for Vim files.

In case of emergency break out this link…

This one isn’t related to Git configuration, but I can’t talk about Git without mentioning this page here. On undoing, fixing, or removing commits in git, is a real life-saver when something bad happens. I have used it myself a couple of times when doing my first rebases on pending pull requests. Next time you realize you have just made a big mistake, follow the instructions on the site by following the hyperlinks.

Contributing to open source projects is something I have long wanted to do. This is why I recently started contributing to reek and I’m happy I did.

One thing I have found out is that it can be hard to find the right project to start contributing to when you’re on a limited time budget.

While browsing repositories on GitHub, I manually filtered out certain repos. Those that hadn’t been updated in months or years, those that hadn’t accepted any pull requests, those that had hundreds of open long standing pull requests with no comments.

While these repos could end up working great for contribution, they feel risky and I prefer to go with safer bets.

Introducing dispatcher

I have decided to write an open source project to help me filter out those repos and present me the ones which would be the most suited to contribution. The results is then presented on a GitHub page and available for all. The project name is dispatcher.

How you can help

If anyone wants to help, please do not hesitate to fork the repo. Do not hesitate to contact me directly if need be.

Besides code contributions, I would appreciate any thoughts on how to better filter the repos. What would turn you off when looking at a project to contribute to? Feel free to submit this by email, commenting on the blog or by submitting new issues on GitHub.