Fork me on GitHub

n. Slang a rough lawless young Kuali developer.
[perhaps variant of Houlihan, Irish surname]
kualiganism n

Blog of an rSmart Java Developer. Full of code examples, solutions, best practices, et al.

Thursday, November 13, 2014

The .gitconfig File

The .gitconfig file I'm talking about is the one in your $HOME directory. This file has all your default settings aside from the global .gitignore file. It's useful because setting your name and email address for each repository is a real pain. There are other settings besides this though. For example, here is my .gitconfig

All of those properties can be added at the repository or global levels. My .gitconfig is sometimes just a reference for commonly-used properties in git. I'll outline a couple of my favorite settings.

signingkey = 2DDF1261

You may remember my post on Signing Git Commits. This is the default PGP key that can be used for signing. Since I have more than one Key (for more than one github identity. eg., work, personal, open source.), I use more than one key to sign with, so this is something that I also put in my repository-level config. That way, I don't sign with the wrong key by mistake. This is my default though.

editor = emacs

This post would not be complete without an emacs plug. I also use emacs for merging and diffing:
    tool = emerge
    prompt = false
    tool = emerge
    prompt = false

The above allows diff'ing and merging straight through emacs without prompt.

autosetuprebase = always

Use this how you like. This property ensures that rebase is the default behavior when merging. This especially effects pulls. Normally, to rebase you have to git fetch. Then, you have to git rebase. A lot of people just will git pull. The trouble with this is that if there are changes, it will merge.
What's wrong with merging?

Well, merging will add another commit hash with a comment and can potentially confuse what happened. Have you ever looked at a repository and saw more merge commits than anything else? Doesn't that make it terribly difficult to find real changes? YES! Here's an example.

Suppose Bob makes a change and creates a pull request on his project 'salad-spinner'. Then Dave pulls in his change. What happens? Well, git will do a merge with a comment stating 'Merge blah blah blah'. Now when Dave does a pull request, guess what happens? That's right. The merge commit gets sent through in the pull request. What does this do? Well, imagine a project with lots of developers and they're all pulling. Lots of merge comments. Now push those back into the main repo, what do you get? Lots of merge comments with very little saying what actually happened.

What should happen?

That's simple. When following the github pull request model, local repos should be rebasing from the remote. They should not be merging. People like to git pull though, right? That's where autosetuprebase = always comes in. It makes it so that the default behavior is rebase instead of merge.

What if I want to merge?

I can't ever see this happening, but if you REALLY MUST, then do git fetch and git merge. This ensures that you only do it when you REALLY REALLY mean to.

lg = log --graph --show-signature

Last one. What's the point of signing your commits if you and others can't see the signatures of you and others? Let's add signatures to all the log statements so we can see the signatures. ^_^


No comments:

Post a Comment