4 ms·
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
by thenduks 17y ago
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.
- vog 17y agoPushing 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 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.)