Bailing out of an in-progress git merge

Git has a number of features that have been around for some time, yet many people seem unaware of. git merge --abort seems to fall into this category. It was introduced in version 1.7.4 (35d2fff), which was released January 30, 2011.

git merge --abort brings further consistency of how to back out of certain operations (git rebase --abort, git am --abort, ...).

Some times you'll come to the decision that the merge in progress (conflicted, or just --no-commit) shouldn't be finished. git merge --abort is likely what you're looking for. This will first check to make sure that you're actually in the middle of a merge (.git/MERGE_HEAD exists), then run git reset --merge for you (the previous way to do this, available since 1.6.2).

While this doesn't do much of anything that wasn't available before, it's nice to have the action available in a form consistent with more well advertised "just make it like it was before" commands (such as git rebase --abort).

Updated git rebase --interactive --autosquash commit preparation

Previously I wrote about git rebase --interactive --autosquash, and showed a couple of helper aliases to aid in creating the specially formatted commit messages used by --autosquash.

In 1.7.4, Git gained built-in versions of these helpers (specifically in d71b8ba and 89ac122). It is now possible to use the commit command directly (or much more simple aliases) to create fixup and squash commits for use with --autosquash.

Read more  ↩︎

How I use different fetch & push URLs in Git

I hate having to enter my ssh key passphrase just to fetch from public Git repositories where I have push access. Fortunately, since version 1.6.4 Git has had the ability to separately specify the URLs to use when fetching, and when pushing. In addition to no longer requiring me to have my SSH key loaded when I go to fetch, I've noticed that fetching is now faster without the overhead of SSH.

In order to configure different fetch, and push URLs, you'll need to add a pushURL setting in the .git/config for the remotes you want configured. With the url setting configured to use a git:// style URL, and the pushURL setup to use an SSH URL (git@ or ssh://), you can avoid the overhead of SSH when fetching, but still be able to push to the repository.

.git/config in the repository

[remote "origin"]
    url = git://github.com/jhelwig/technosorcery.net.git
    pushURL = git@github.com:jhelwig/technosorcery.net.git
    fetch = +refs/heads/*:refs/remotes/origin/*

This particularly comes in handy on machines where I have GPG Agent setup to be my SSH Agent (since I have GPG Agent setup with a timeout which requires unlocking the keys again), and also with projects where I have multiple remotes where I can push.

Using Git's @{-1} notation

There are a number of features Git has had for some time that go largely unnoticed by most people. Being able to refer to branches using the @{-1} notation (and its - alias) is one of the features I use on a regular basis that most people seem unaware of, even though they've been around since version 1.6.2.

Read more  ↩︎

Using Git's @{upstream} notation

One useful feature Git has had since 1.7.0 is the ability to refer to the branch that another one is tracking using [branch]@{upstream} notation. I've found this especially handy while working on projects with multiple committers.

Read more  ↩︎

Making 'git push' a little smarter/safer

Without any additional command line options git push's behavior is almost never what I actually want it to do, since I rarely wish to push more than one branch at once, and often work with multiple remotes where I have push access.

Even though I am generally in the habit of always supplying both the remote and a list of refs when pushing (git push <remote> <ref1> [..<refN>]) I'd rather not have anything potentially dangerous or unwanted happen if I happen to leave off the ref(s) (or very rarely both the remote and the ref(s)).

Read more  ↩︎

Making Git a little less verbose

Git has some output that can be very helpful to people getting started with it. Once you've been using Git for a while, however, you may find that the advice that Git provides to help deal with certain situations just ends up taking up screen real estate. Fortunately, there is a way to turn off a number of these messages.

Read more  ↩︎

Colorizing Git output

There is a simple tweak to make working with Git a lot nicer that people often don't know about, or forget to do is turn on Git's ability to colorize its output.

Read more  ↩︎

Offline email with gmail, mutt, postfix and offlineimap

One of my co-workers recently asked me to send him my setup for being able to read & write email while fully disconnected from the internet using mutt.

Read more  ↩︎

Pitfalls with RPM and GPG

As part of automating the packaging process for Puppet Dashboard we ran into some baffling issues regarding the package signatures. Initially, we ended up with a package that was recognized as having a valid signature on some systems, but not others (Good with RPM 4.7.2, bad with 4.4.2.3). Additionally, when we tried signing the package with our "normal" GPG keys to try and debug this, we were unable to get a good signature from any of the systems we were testing with.

After much cursing, and Googling, we were able to find the correct incantation to get past the gauntlet of bizarre RPM behavior.

Read more  ↩︎