Puppet is the more mature technology of the two, but (so I'm told) there's an important limitation in that there is no way to automatically e.g. reload the web server if its config file changes. Both these systems have some issues with information flowing in only one direction.
The only trick is that Puppet must be aware of the file change. This happens automatically when the file is modified by Puppet. But if it's modified externally by a shell script or a git pull, you need to have Puppet copy that file to another "dummy" file, so it can detect that it changed from the previous version and trigger the restart.
What a "service restart" means can also be configured if you want a SIGHUP or something else. The default is the equivalent of "/etc/init.d/nginx restart".
Getting to that point can take quite a bit of effort though. In my most recent attempt to install a Chef server on a fresh Ubuntu box, I quit the installation halfway through as I realised I wanted to change some of the values I'd entered into the setup script. After re-running the script I encountered errors, and all my attempts at scrubbing the aborted installation failed. It was easier to just start with a fresh image. I had these sorts of experiences all the time when using Chef and Puppet, they were really frustrating to setup.
I felt more comfortable writing my scripts in Chef because it didn't limit my ability to use Ruby, and the more relaxed approach to handling dependencies suited me. Puppet was easier to setup, had better documentation, and behaved more reliably for me. Neither seems like a clear winner, but I haven't spent a lot of time with them in about a year now, so things may have changed!
Basically, I liked how chef treated the terminals as "dumb" and the configuration could be stored in source control. All of my nodes/"cookbooks"/recipes/users/data bags are stored in version control, with a few simple shell scripts to batch load the data. Also, chef nodes ping back to the server, which could cause problems (if you had tens of thousands of nodes hitting frequently), but also solves issues like "what if a server is offline when an important update should be pushed"
I believe that puppet has far more tools for seeing what's going on with your servers, when they last updated, that kind of thing. Also, the recipes/cookbooks you can get from the chef repository can be a little hit and miss (I had to heavily modify a few to make them work in my environment)
The built in reporting in Chef isn't very useful and the web ui is pretty light, but there's at least hooks and examples on how to extend it to meet your requirements.
Most of the Chef development so far appears to have been focused on core features and most recently a simplified installer - hopefully reporting will become a focus as the product matures.
Chef has invented a new object system and execution model within Ruby.
Neither's approach is particularly good in this respect, but the latter is less onerous.
As I've said in the past, the consensus is simply "use a CM system," especially if you have to maintain these machines for a while (or if you have 50+ machines to take care of.) It's much better than dealing with various shell scripts or whatever else.
Capistrano is a tool for deploying your applications. You use it to push out new versions of your own codebase.
Chef and Puppet are tools for provisioning/configuring servers. You use it to install the right third-party libraries, programs, config files, etc.
