It turns out that it is quite simple to set up a minimal GPG environment – one that lets you work on the command line without having to set it up for Mail.app. This is about all I need it for.

The GPGTools project has recently resurrected the MacGPG project to provide email encryption and tools to the Mac. It is still in development, and I didn’t want to mess about with my Mail installation so rather than install the complete set of tools, I chose to install MacGPG2 and GPGKeychain Access

MacGPG2 is the OpenPGP implementation for the Mac. This installs gpg2 into /usr/local/bin and gpg is symlinked to gpg2. I only mention this because although the commands can all be issued as gpg, you get to the documentation by using man gpg2, not man gpg. Installation is through an installer package.

GPGKeychain Access does not integrate with the Mac Keychain as the name might suggest, but provides a window to look at and manage the keys that you have on your system. These are usually under ~/.gnupg/ Run the installer, and create your keys. It’s quite simple and there is a video on the project page. However, there are a couple of things that you should keep in mind. If you forget your passphrase you can’t use your private key anymore. And if you’ve published the key, you won’t be able to revoke it and it will just sit around on keyservers. So, set an expiry date on your keys in case you do lose the private key or passphrase. As the expiry date comes up just extend it again.

There is no key-server configured. There seems to be a ticket for this to be implemented in some future milestone. Until then, create a file called gpg.conf under ~/.gnupg and put this line in it:

keyserver hkp://pgp.mit.edu

And that is just enough so that when you use the menu items that send and get keys from keyservers they will work. As far as I know, these servers talk to each other, so writing to one makes the key visible on the others.

Synchronisation of keys is an issue. If you are adventurous you could add more entries to the gpg.conf file to use a central location for the keyrings, somewhere like Dropbox or iDisk, so that all your machines can use the same files. But, it’s just as easy to export the keys as text and use those files to keep different machines in sync. Partcularly if you will be using gpg rarely.

This has been a companion piece to the non-Mac centric 365Git post about signed tags.

20 minutes is far too short to cover such a large subject but I did what I could. I have been given another opportunity to present in the future and I’m going to skip the boring beginner bits and just cover 3 or 4 advanced Git techniques which should be more fun.

For what it’s worth, here are the slides. Probably not much help unless you were there (I prefer more talk and less slides) and I apologise for being weak and using bullet points.

Download the Keynote presentation (540 kb)

Download the PDF slides (220 kb)

Download the Keynote presentation (1.1 Mb)

Download the Slides as a PDF file (1.7 Mb)

And this week Alex Blewitt (@alblue) will be talking about DVCS and Git. Yes, that’s right; someone else is going to be talking about Git.

So come along for the usual collection (array or set, your choice) of chat, food, drink and learning. Nourishment for body and mind. And me telling you how you should always work on a private branch and that commit messages should be written in the present tense.

Where: The George Inn, Borough High Street
When: 6:30 pm onwards

Our evenings don’t usually follow the norm of people all sat down and coding. I suppose that’s because of the choice of venue, but who would turn up for an evening in Starbucks?

I’ve got a couple of volunteers lined up for the next couple of meetings, but I thought it would be a good idea to put some draft ground rules down.

For Presenters:

Keep talks short and focussed. 15-20 minutes should be enough time. Think of it as being an initiator of the discussion that might follow.

Forget about any audio-video support. We are in a pub, where there are other people around. A few slides on your laptop or iPad is the most you have to work with. If you do a slideshow I’ll happily host the slides or post a link back to where you have them.

Don’t be offended if not everyone listens to your presentation, or scuttle off during it. Some people are just not interested in the topic, or are having a more interesting discussion somewhere else. The talks are not the point of the evening, just something that happens during the evening.

Be prepared to expand upon and explain your ideas further if someone asks.

For Listeners:

Don’t feel you have to listen to the talk if you don’t want to, but please don’t have a conversation over it. If you start listening and decide to bail, do so in the least disruptive way possible.

Ask questions, make comments, ask for help with related code. The presentations are necessarily short, but that doesn’t mean you can’t keep talking about the topic.

If you feel you have something to talk about, let me know and I’ll add you to the list.

Upcoming Talks:

August – Richard Buckle on Test Driven Development
September – Alex Blewitt on Git/DVCS

If anyone has any amendments to propose for these rules or have subjects for talks, please let me know. See you on August 17th.

I’m going to try and and fill a year with git tips and inspirations over at 365git. I’ve got a few weeks worth of ideas but if anyone wants to know anything or has a suggestion, I’ll gratefully consider them.

There are three types of exclude files; from highest to lowest order of precedence they are:

Per Project: .gitignore file in the repository

This is the usual way of adding an ignore file. Call it .gitignore and save it to the root of your project to apply to all the files (you can add different .gitignore files in subdirectories where they have lesser scope). It is a part of the repository, so it will need to be git-added and committed for each change. This is useful for repositories that are passed around with others who may not have a per computer exclude file, or when there are project specific files that need to be taken into account. Even easier if you have per computer file, you can copy it straight in to your project with a simple cp ~/.gitignore .gitignore and edit to handle your specific requirements.

Per Repository: in .git/info/excludes

You can exclude files on a per repository basis by editing the .git/info/excludes file in your repository. (Why it takes it from this location rather than .git/config I don’t know: add it to the list of git annoyances). These exclusions (or inclusions, you can override the higher level exclusions by prepending ! to lines that you want to include) are not shared with the working directory, so they only apply to that particular repository. This is useful when you have particular requirements because of your workflow or machine setup.

Per Computer: through ~/.gitconfig settings

There should already be a .gitconfig file in your home directory. This is where the global setting for your git installation are stored; such as the user’s name and email address. Within this you can set a path to an excludes file that will apply to all git repositories on the computer in the same way as the name and email defined in this file apply to all repositories.

For example: Most of what I do is in Xcode so I have the following ~/.gitignore file

And in my .gitconfig file under the [core] section I have added the path to this file for the excludesfile key. (If you’re sharp eyed, you’ll notice that I don’t have an exclusion for /build. That’s because I don’t keep my products in my project directory, but that’s for a different post).

Now, I have a standard set of ignores that apply to all my git repositories on this machine without me having to add a specific .gitignore file to each one. This is probably most useful if you create a lot of repositories for yourself, but I recommend it to everyone. It’s lowest on the precedence scale and provides a neat catch-all.

Summary

Most of the time the first solution is quite adequate, having exclusions with a repository that is likely to have a public face is probably the most effective way of managing file visibility. But, as with most of git, there are ways of handling edge cases. You just need to know that they are there.

Related Reading

If you liked this post, have a look at my 365Git site for more tips.

REFERENCE: the gitignore man page.

Use a static analyser.

You can use the Clang Static Analyser in Xcode by setting a build option. This will find a whole host of errors in your code, even down to unconventionally named functions.

Now you can just code away and have the compiler pick up your mistakes when you run ‘Build and Analyze’ (Shift ⌘ A).

Find your mistakes quickly

Any real application you develop will have a large number of resources that need to be copied to your application bundle. The default projects that Xcode create for you will copy these files first before compiling.

But, the lazy Xcoder knows that there are probably errors in the code that need to get flagged by the compiler, so this copying is a waste of time. Reorder the build steps by dragging so that the compilation is done first.

Your builds will now break early (and often!).

Don’t fear the version controller

I’m going to stick my neck out and say that if you’re not using version control you’re an idiot. The lazy Xcoder uses a powerful system that lets him or her branch easily, make lots of little changes, and lots of mistakes (that can be backed out). These changes can then be bundled into larger commits to be merged into the main branch so that your co-workers don’t see what an idiot you’ve been.

One such version control system is git. The lazy Xcoder writes a bit of code, checks it in out of habit and then compiles. The compiler picks up the mistakes, and he or she fixes them. Rather than make a new commit, and retype the commit message, just call:

git commit --amend -a -C HEAD

This will bring up the previous commit message in the editor, which you can amend if you wish. This new commit will replace the previous one. The -a option means you don’t even need to do a git add and the -C HEAD option means it will use the commit message from the last commit.

Of course, if you’re a rockstar programmer, you don’t make mistakes at this level. But I’m not, and I prefer to work with human nature rather than against it.

Changes Support

Step One: Make sure chdiff is installed.

Open Changes.app and from the Changes menu select “Install terminal utility”. This will install the chdiff utility which is used by the script.

Step Two: Create a shell script to send diffs to Changes

Create a shell script with the following contents.

Where you save this and what you call it is up to you. Mine is called ‘.gitchanges’, saved it at the root of my home directory. Make sure the script is executable.

Step Three: Edit the .gitconfig file to use this script to handle diffs.

Open your ~/.gitconfig file. This should already exist, at the very least it will contain you name and email. under the section called [diff] add the location and name of the file. You may have to edit this to make sure it points to the name and location you chose in Step Two. (Make sure to use the correct path in your setup)

SubEthaEdit Support

Step One: Download and install the mode file for SubEthaEdit

I wrote a SubEthaEdit mode for this which you can download from the github project page. Please feel free to fork it and send me patches.

Step Two: Edit the .gitconfig file to use SebEthaEdit as an external editor.

Open your ~/.gitconfig file. This time, under the [core] section, add the following line:

All those flags may seem daunting, but they are quite self-explanatory: the -w flag makes the Terminal wait for a response from SubEthaEdit. -r brings Terminal to the front after you’re done editing. -o new-window opens a new window for editing. I prefer this to having a new tab appear in whatever window I was working on. -j 'git editor‘ this sets the text that appears in the title bar, which you can change as you wish. -m gitCommit is what sets the mode to be used for editing. and -g 1:0 puts the caret at the beginning of the file.

Now, when git asks you to write a commit message, or pick commits when running git rebase -i a SubEthaEdit window will open as the commit message editor. Make whatever changes you need then save the file (⌘-s) and then close the window (⌘-w) for these changes to take effect.