I have been doing a lot of piecing out commits to break them into related feature-coherent sets lately, so I thought I’d share the webpage I used as a reference.

Basically the mechanism uses the same git rebase –interactive that you can use to squash commits, but instead opens one for editing mid-rebase.  Then you can revert it, and use git add -p filename for an interactive selection of chunks to leave in or out.  Add some git commit for your new pieces, and then git rebase –continue to finish.

Complete steps here.  The payoff is that git add -p is a great complement to interactive rebase.

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\$ "

One of the joys–or perils, depending on how it’s going–of any big development project is housed in the usefulness of the tools you use to manage it.  In Koha’s case, git is where we keep our code, and there are a number of repositories, both inside and outside LibLime, where we keep up with things.

I’m still trying to decide if git is a blessing, or a curse.  When everything is going right, and I’m using it to update our customer sites, I think very highly of it. A fistful of commands in bash, and the customer is up-to-date–what’s not to like about that?

But I’m making some small forays into development.  Little stuff, mostly things that affect me installing and keeping Koha and its’ infrastructure happy.  Shouldn’t be too hard, right?

Here’s a tip: the coding is the easy part.

I had to look up (again) how to extract what I’d done as a patch.  Okay…I made up my little edit, and did git-commit and git-format-patch to make a nice little file to git-send-email it…

…and discovered that my MacBook’s postfix isn’t running.  Lovely.  So I spent an hour putzing with that, trying to get it working–it runs, but it won’t talk to anyone–and finally had a V-8 moment, and uploaded the patch to our development server, and git-send-email’ed it from there.

I’m sure the “real” developers who contribute here are all laughing like hyenas at my thrashing around trying to get a 5-line patch out.  I’m sure Joe or Galen could have handled this in their sleep.

But doggone it, I’m proud of that little patch!  Not for its’ contents, which are trivial at best, but because I managed to coax it out into the light of day, without help!

Seriously, git is a great tool for managing code in a distributed-work way.  It just seems like Dark Arts at first…

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