It came about that I wanted to do some work with git and signed tags. It’s been a while since I had looked at this, I’ve got some old entries up on keyservers that date back to 1999, and never on a Mac.
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.
I’ve been inspired by Pieter Omvlee of Bohemian Coding and his 365Cocoa to set up my own contribution.
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.
Almost every git user knows about adding a .gitignore file to their repository to control the visibility of files and folders. This per project configuration will apply to all repositories of the same code base. But it’s not the only way. I’m going to tell you how to get git to ignore files on a per computer and per repository basis. These could be better choices in some circumstances.
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.
