Chris Cormack shared this useful trick for keeping track of what git repo you are currently using/editing. Stick it in your .bash_profile to have your prompt adapt to the repo you are in!

function parse_git_branch {
  ref=$(git-symbolic-ref HEAD 2> /dev/null) || return
  echo "("${ref#refs/heads/}")"
}

RED    ="\[\033[0;31m\]"
YELLOW ="\[\033[0;33m\]"
GREEN  ="\[\033[0;32m\]"

PS1="$RED\$(date +%H:%M) \w$YELLOW \$(parse_git_branch)$GREEN\$ "

When you use git format-patch and git send-email to format and mail a patch, the subject line of the email becomes

[PATCH] first line of commit message

Since patches go through a mailing list, mailman adds a prefix of its own:

[Koha-patches] [PATCH] first line of commit message

When the patch is applied, git am invokes git mailinfo to clean up the subject line, including whitespace, “Re:”, and any leading sets of text in square brackets. However, it can be a little too greedy.

If your original commit message starts with

[bug 1234] add automatic whale-saving,

the patch will reach me with the subject line

[Koha-patches] [PATCH] [bug 1234] add automatic whale-saving.

However, git am (as of 1.5.5, at any rate) will chomp it down to

add automatic whale-saving.

Oops! No bug number to immortalize your rescue of cetaceans via an ILS!

To avoid that, try bug 1234: ..., (bug 1234) ..., or if you really like square brackets, move it to the end: ... [bug 1234].

I’m pointing out a change that Frédéric Demians made recently to the Git usage page on the Koha development wiki.

In order to avoid mangling non-ASCII characters in commit messages for patches submitted via git-send-email, Frédéric suggests forcing the Content-Type header in patches prepared by git-format-patch to specify UTF-8. This can be configured like this:

git config --global format.headers "Content-Type: text/plain; charset=\"utf-8\""