After spending the evening in the Old Bar which was mostly empty we thought we’d try and have the next meeting there as well. Far more space and quiet enough to hear everybody. This could have been because people had gone elsewhere to watch the football or were sitting on the benches outside to enjoy the clement weather. The downside was that the food wasn’t as good.

So, for next month, we’ll try and have the meeting at the George Inn and see how it copes with a larger group of people, and for those who turn up early they can go to the Bunch of Grapes for food. There is no point in trying to arrange dinner afterwards because people have got trains to catch.

View Larger Map

The other idea I had was to gather on the embankment outside the London Assembly building. But the weather reports say it might be windy.

This is just a temporary location for a week.

Tomorrow is the third Tuesday of the month, and that means another London Mac developer get together.

See you there.

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.

Here’s an old screencast which I never got around to uploading.

It makes sense to set up a single directory in Xcode where built products and intermediate files are kept. You can blitz all the files at once if you don’t need them, you don’t have to set up manual exclusions for your version control and you can set up the files to be excluded from Time Machine backups.

This was recorded with an earlier version of Xcode, but the steps still apply. Please excuse the sound quality.

The meeting is at the usual place at the usual time. There is a table booked upstairs from 7pm. Send me an email or a DM on twitter if you need my phone number or any other details.

As it’s such a nice day, I might turn up early. See you later.

You can find step-by-step instructions and scripts with a little bit of Googling. But there is another way. If you’re running Xcode 3.2 on Snow Leopard there is a menu item you can use instead. Have a look at the Project > Rename… menu item instead.

It’s a great idea and starts with a useful category on NSArray. Go and see what you can learn over at http://365cocoa.tumblr.com/.

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.

REFERENCE: the gitignore man page.

WiFi can be spotty in the pub, so if you want to be sure to find us drop me a message and I’ll let you have my mobile number. There is food available until 9pm if you’re likely to be hungry. Unfortunately, there is a minimum age of 21.

As usual, you don’t have to bring a laptop and code; you can just come and be social.

Finally, at one of last year’s meetings, mention was made of having a Cocoa hackday along the lines of CocoaDevHouse. If you have any ideas for this or have experience in setting up these kinds of events I’d love to talk to you about taking this further.

See you tomorrow.