I think the simple answer to this one is that it's a universal deployment tool. Like it or not, anyone who uses git can use it.

If I'm working on a Python project, I could possibly create a Fabric file to help automate the deployment. Anyone working on the same project would have to install Fabric, and figure out any quirks it has.

The same then applies to every other language. They tend to recreate deployment tools in their own language to solve the exact same problem. Capistrano for Ruby, etc. Everyone has to learn the deployment process for each different project.

Using git as a deployment tool means that the only person who has to worry about the deployment process is the one who creates the server side commit hook/push scripts. All the complexity is taken away, they just have to say "push to git@example.org" and all the magic behind it is taken care of.

It's universal between all projects. If I'm running a PaaS, all I have to tell my users is to put files in a specific place, add a config file, push to our servers. Without this, users of every language might need specific deployment tools, or be forced to use a generic one which might not suit their needs.

Because any application that can copy files over a network is eventually used as a deployment tool. I'm sure there's a netcat deployment tool out there somewhere. ("Hey look, with the -e option I can run a script to process the deployment on delivery!")

That's a really odd comment to make. Surely automating the steps to deployment is a good thing.

Git has hooks for kicking off processes, its extensible, deployment scripts don't alter the core of git. What's the problem with evolving something?

I don't know, but it's a very annoying trend.

I appreciate the work that has gone into this code, but if you want to deploy using source control then you should really be looking into continuous integration and deployment.

I'm not trying to use it as a deployment tool, I'm building a lightweight deployment tool over it and SSH.

These two things typically go hand in hand. I personally use git to version my deployments. So, I'll check something into git, and then have it do a deployment via a git post commit hook. This is very handy, in that I have a history of what was deployed along with the changes. I can also easy revert changes and they get pushed out. So, we are distilling a deployment (which typically has many steps) into a 'git push' workflow.

Because it works very well and the tasks aren't really all that different? Push changes, synchronise files across machines.

Because my repo is clean whilst my working folder is messy.