You probably want to use a bare repository (git init --bare) rather than `git config receive.denyCurrentBranch updateInstead`, which will cause your pushes to fail if you edit anything locally in the checkout. For http://canonical.org/~kragen/sw/dev3/ I run a pull from the post-update hook of http://canonical.org/~kragen/sw/dev3.git, http://canonical.org/~kragen/sw/dev3.git/hooks/post-update, which is short enough that I'll just include it here:
#!/bin/sh
set -e
echo -n 'updating... '
git update-server-info
echo 'done. going to dev3'
cd /home/kragen/public_html/sw/dev3
echo -n 'pulling... '
env -u GIT_DIR git pull
echo -n 'updating... '
env -u GIT_DIR git update-server-info
echo 'done.'
You can of course also run a local site generator here as well, although for dev3 I took a lighter-weight approach — I just checked in the HEADER.html file that Apache FancyIndexing defaults to including above the file directory listing and tweaked some content-types in the .htaccess file.
This could still fail to update the checkout if it has local changes, but only if they create a merge conflict, and it won't fail to update the bare repo, which is probably what your other checkouts are cloned from and therefore where they'll be pulling from.
Also bare repositories are a useful thing to put on USB pendrives.
For a USB drive, I would be more likely to use a bundle. Intended for offline distribution of a repository. Plus it is a single file, so you do not have to pay the transfer overhead of many small files.
You can repack your repo before you clone it onto the pendrive, and once it's there you can push and pull to it many times. Granted, pendrives are fast enough these days that copying an entire bundle every time is probably fine.
regarding that post-update script, can you explain?
I would think you'd want to
..in that order.
And I wouldn't think you'd need to run git update-server-info again, after git pull. My understanding isthe update-server-info makes updates to info/refs , which is necessary _after a push_.
What am I missing?
The first update-server-info is running in the bare repo, which is the place I just pushed to, which is where sw/dev3 is going to pull from.
I'm not sure the second update-server-info is necessary.
If you're asking about the env -u, that's because Git sets that variable so that commands know which repo they're in even if you cd somewhere else, which is exactly what I don't want.