git-config Settings You Want

Git comes with some fairly lkml-specific configuration defaults. You should fix this. All of the items below can be set either for your entire login account (git config --global) or for a specific repository (git config).

Full documentation is under git help config, unless otherwise stated.

  • git config user.name 'Your Full Name' and git config user.email 'your-email@example.com', obviously. Git will remind you about this if you forget.

  • git config merge.defaultToUpstream true - causes an unqualified git merge to merge the current branch's configured upstream branch, rather than being an error. This makes git merge much more consistent with git rebase, and as the two tools fill very similar workflow niches, it's nice to have them behave similarly.

  • git config rebase.autosquash true - causes git rebase -i to parse magic comments created by git commit --squash=some-hash and git commit --fixup=some-hash and reorder the commit list before presenting it for further editing. See the descriptions of “squash” and “fixup” in git help rebase for details; autosquash makes amending commits other than the most recent easier and less error-prone.

  • git config branch.autosetupmerge always - newly-created branches whose start point is a branch (git checkout master -b some-feature, git branch some-feature origin/develop, and so on) will be configured to have the start point branch as their upstream. By default (with true rather than always) this only happens when the start point is a remote-tracking branch.

  • git config rerere.enabled true - enable “reuse recorded resolution.” The git help rerere docs explain it pretty well, but the short version is that git can record how you resolve conflicts during a “test” merge and reuse the same approach when resolving the same conflict later, in a “real” merge.

For advanced users

A few things are nice when you're getting started, but become annoying when you no longer need them.

  • git config advice.detachedHead - if you already understand the difference between having a branch checked out and having a commit checked out, and already understand what “detached head” means, the warning on every git checkout ...some detached thing... isn't helping anyone. This is also useful repositories used for deployment, where specific commits (from tags, for example) are regularly checked out.