Mainly putting this up here so that it is hopefully findable by others, since I had such trouble finding it online when I was looking. The GK12S manual doesn't appear to be on Epomaker's site anywhere (at least at the time of writing this).

Mainly putting this up here so that it is hopefully findable by others, since I had such trouble finding it online when I was looking. The GK12S manual doesn't appear to be on Epomaker's site anywhere (at least at the time of writing this).
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
.
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.
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.
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.