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).

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.

Ben Hengst recently acquired a pretty nice find from the Salvation Army Goodwill, with one slight problem.

This item seems to be near non-existant on the internet, when it comes to useful information (such as pinouts, and what’s necessary to actually capture at 10000 FPS).

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.

1
2
3
4

[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.

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.

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.

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)).

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.

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.

A while back, I ditched Mephisto in favor of a static site generator I’d written in Perl (WWW::StaticBlog). When setting up a new laptop, and preparing to write a new post, I discovered that one of its dependencies (Text::Multi) is no longer on CPAN. In my haste to set something up I ended up deploying a new version of the site using nanoc, before fully working out the kinks. Turns out that nanoc doesn’t really support having pygments output line numbers in the “table” format, and working on fixing this was more work than I was willing to put in when there are many alternatives out there.