3 ms·

When you Git push to a live server as the article in question suggests you're sending the entire repo history not just the latest commit. The remote hook only

by tux1968 13y ago

When you Git push to a live server as the article in question suggests you're sending the entire repo history not just the latest commit. The remote hook only checks out the latest change, but the entire history is sitting right there on the live server. Which is silliness in most cases. As is suggested in the SO article you link, it's more appropriate to locally export the version you want to deploy and use ssh (or whatever) to transfer it to the live server. Nobody ever seems to try to justify _why_ you would want to use git-push, they just go about explaining how you do it.

Aqueous 13y ago
In this example they are checking out into a work tree that is detached from the central repo, which is bare (or could be.) Therefore there is no .git directory in the work tree and the history is inaccessible from the outside world. I don't see how having the entire history sitting in a private directory on the server is silly, as long as only you can access it. Honestly we are just talking about transferring files here. However you automate it, as long as it gets the files from point a from point b, is fine. I happen to find it most convenient to use git since that is how I send and receive code changes everywhere else, and it seems foolhardy to introduce another file transferring tool without a really good reason why. Moreover it lets me very easily tell exactly what revision is sitting on the server, and also causes me to pause before I push. It is also really easy to integrate git, through hooks, with a continuous integration setup.
kaoD 13y ago
> _why_ you would want to use git-push Faster deployment. As I said you shouldn't use this for critical services, but it works great for quick hacking. It's also very convenient for non-production (i.e. testing/staging) machines, to automate continuous integration.
gkop 13y ago
> _why_ you would want to use git-push Many of us like to have some recent past releases sitting on the production servers in order to make instant rollbacks if we discover a bug after the code has been deployed. Git provides that for free.
- bradleyland 13y ago
  This is almost exactly what Capistrano does. What's hilarious is that this entire thread reads like a discussion that could have lead to the development of Capistrano. * Capistrano can deploy via git (it uses export) * Capistrano keeps a configurable number of releases around in case you need to rollback * Capistrano provides an ordered task system with before/after hooks at every one of its pre-defined tasks * Capistrano can be just as lightweight as using git to deploy: cap deploy git push Two additional characters! * You may not need all the stuff that Capistrano provides today, but as your project grows, you will need it. Why waste your time with a compromised deployment hack when better tools are available and easy to use?

by tux1968 13y ago

Aqueous 13y ago

In this example they are checking out into a work tree that is detached from the central repo, which is bare (or could be.) Therefore there is no .git directory in the work tree and the history is inaccessible from the outside world. I don't see how having the entire history sitting in a private directory on the server is silly, as long as only you can access it. Honestly we are just talking about transferring files here. However you automate it, as long as it gets the files from point a from point b, is fine. I happen to find it most convenient to use git since that is how I send and receive code changes everywhere else, and it seems foolhardy to introduce another file transferring tool without a really good reason why. Moreover it lets me very easily tell exactly what revision is sitting on the server, and also causes me to pause before I push. It is also really easy to integrate git, through hooks, with a continuous integration setup.

kaoD 13y ago

> _why_ you would want to use git-push Faster deployment. As I said you shouldn't use this for critical services, but it works great for quick hacking. It's also very convenient for non-production (i.e. testing/staging) machines, to automate continuous integration.

gkop 13y ago

> _why_ you would want to use git-push Many of us like to have some recent past releases sitting on the production servers in order to make instant rollbacks if we discover a bug after the code has been deployed. Git provides that for free.

bradleyland 13y ago
This is almost exactly what Capistrano does. What's hilarious is that this entire thread reads like a discussion that could have lead to the development of Capistrano. * Capistrano can deploy via git (it uses export) * Capistrano keeps a configurable number of releases around in case you need to rollback * Capistrano provides an ordered task system with before/after hooks at every one of its pre-defined tasks * Capistrano can be just as lightweight as using git to deploy: cap deploy git push Two additional characters! * You may not need all the stuff that Capistrano provides today, but as your project grows, you will need it. Why waste your time with a compromised deployment hack when better tools are available and easy to use?