If "git push" would work properly for non-bare destinations (as it is the case with e.g. Mercurial and also Darcs), the design could be simplified by merging "hub" and "prime".
That's true, but unfortunately, trashing is the default.
Without any hooks, the next "git commit" on the remote system would add a patch that reverts the uploaded changes. This is very contra-intuitive and could be the source of big mistakes. It's a really nasty trap if you don't watch out!
I like more the approach of Marcurial and Darcs where "not trashing" is the default.
I guess I don't know how it works on hg or darcs, but I appreciate the bare repositories and git's reluctance to push on top of a checked-out working copy. It's not too hard to add hooks that make things automatic if one is so inclined, as we see in this case.
As for me, I just type the extra "git pull" or "git push". It's not a big deal for my use case right now, though if it were I know it's fairly simple to add hooks that automatically pull changes into your running copy ("Prime"), though I'm not sure I want that. I like pushing to the hub and controlling when those changes get rolled out without having to maintain a ton of different branches.
Unfortunately, it's not just a hook. It's a whole new repository clone just to maintain a checked-out working copy. The whole synchronization process between them is simply unnecessary.
BTW, in Mercurial it is indeed just a hook. And in Darcs even that hook isn't needed.
And FWIW, Mercurial can handle bare repositories, too.
The original article wants to do exactly that, so it would profit from a better-designed "git push".
Also, Git was never designed for minimalism, but rather for feature-completeness. In contrast, Mercurial was designed with a minimalistic approach (as least in the beginning), so I find it especially strange that Mercurial provides a proper "push" but Git doesn't.
Just because git gives you a method (hooks) to do stupid things doesn't mean they should be built into it. Pushing to a live site (or even just the implied case of pushing into a non-bare repo) is a bad idea. If you want to use hooks (or you own script, or scp, or whatever) to do it you can.
1) "Pushing to a live site is a bad idea."
2) "Pushing into a non-bare repo is a bad idea."
both don't hold.
Regarding 1): It depends on how well-tested the code you're pushing is. Also, conceptually it doesn't matter whether you deploy by pushing to the live system, or by triggering a script on the live system which pulls from the test system. Both achieve exactly the same, so both are equally good or bad. However, the push is more comfortable.
Regarding 2): I have a scenario at home where such a push makes a lot of sense. There is a stationary computer and a laptop, both of which have a common document repository (using Mercurial). Synchronization happens when the laptop is at home. It's just "hg pull -u ; hg push". The laptop needs access to the stationary computer, but not vice versa.
If I avoided the push, I'd have to trigger a script on the stationary computer which in turn pulls from the laptop. Net result: One more script and one more communication channel, i.e. more work and less security.
So please be careful with exaggerated generalizations.
Sorry, I still maintain that pushing to a live site is a bad idea -- and that includes indirectly pushing to it with a auto-triggered script. Deployment should always be a deliberate operation and not related to simply pushing code to a blessed repo.
About (2), the script approach is the right one here. Again, just because you have some case where pushing to a working copy is easier doesn't mean git should make that a feature. Write the script once, problem solved.
Pushing code to the "production repo" is a deliberate operation. Running "git push production" is as explicit as "./deploy-to-production.sh".
Also, nothing against scripting. Mercurial needed a small hook, too. But Git's default push behaviour is not only worthless, it's dangerous and risks unexpected reverts of changesets. I already explained this in: http://news.ycombinator.com/item?id=1158563
Git should either have a sane default implementation, or should refuse to push to non-bare repositories. But its current implementation doesn't make any sense. Providing dangerous defaults because people shouldn't use it anyway? That's plain ignorance.
(However, I agree that automatic deployment is indeed a bad idea, no matter whether it uses push or pull. But that's off-topic.)
"yum install". We write a .spec file for each service we deploy, and when we're ready to deploy we compile and package the current release branch. That way the OS package manager knows what's installed where, whether any dependencies also need to be installed or upgraded, and whether local edits should be preserved or renamed.
I've never understood how "git pull" is supposed to configure a production server correctly. What do people do, put /usr/bin and /usr/lib64 and /etc in git?
Although it is usually not done with /usr/*, it is quite common to put a server's /etc under version control. But that's for administrative control, and is usually completely separate from the web application.
However, it is quite common to use rsync for deployment of everything: system, application, etc. from test to production, without any version control needed. This works especially well when using vservers.
i'm just updating a web app in /var/sites. git pull followed by an alias to a few commands to rebuild templates and reload the server.
i guess there are at least two views of updating web servers: the servers themselves and the web application. the latter is a lot more self contained. i forgot about the former. i set that up once, backed it up, and pray that i don't have to touch it again :-p
