unicornucopious

It's a little early for me to be singing NanoBlogger's praises. However, the tool's design is exactly in line with how I like to work. This isn't my first blog, but this may be the first time I enjoy it and stick with it.

I've been working out what the various files are for. It's not out of curiosity as much as cleanliness:

• I want to deploy only the files that will be viewed and that have changed.
• I want to source-control only the files that NanoBlogger can't generate from the other files. This keeps the "add" operations and repo clutter to a minimum.

I think I've solved these problems. First, what files to push? Here's the relevant part of my custom push.sh:

FIND_ARGS="-mtime -1"

# Loop through all files, filter for the files we want
for push_file in `find ./* ${FIND_ARGS} | sed "s/^.\///" | 
grep -v "^templates" | grep -v "push.sh" | grep -v "^data" | 
grep -v "^blog.conf" | grep -v "^drafts" | grep -v "^parts" | 
grep -v "^cache"`; do

...

done

The shell gurus will probably pounce on my bad form, but you can get the idea: templates, data, parts, and cache directories serve no purpose on the web server. Also, by limiting the find results to only the files that have changed in the last 24 hours, it will avoid pushing out the files that should grow stale - css, images, etc.

So what files should be kept out of version control? My .gitignore:

index.html
rss.xml
atom.xml
archives/*
parts/*
cache/*

The caveat is that NanoBlogger requires the parts and cache dirs to exist, even if they're empty. Git seems to have a quirk where it doesn't like adding an empty dir to version control, so I added some dummy files cache/gitplaceholder.txt and parts/gitplaceholder.txt.

Hopefully someone finds this useful.