Would allow reverting when things go wrong. Ideally, would have support for "HEAD" (HEAD being the default when the argument is omitted).
Tinkering with the idea of a "previous", which would allow you to revert without having to find the previous revision's hash. But, "previous" is ambiguous. Previous revision or previous deployed commit? In the case of previous revision, it'd be easy. But what if a guy made 50 revisions since the last deployment, then deploys them all? Then "previous" would revert one revision, but leave the other 49 revisions. Pretty stupid, IMHO.
So, it is my opinion that the previous deployed revision should be stored in a PREVIOUS_REVISION file, along with the REVISION file. That file would allow doing git-deploy-php [deploy-file] previous, and easily revert to the previously deployed revision. So if you deploy something that breaks your production website website, git-deploy-php production previous would fix it. Pretty neat. :D
The ability to do:
git-deploy-php [deploy-file] [revision-hash]Would allow reverting when things go wrong. Ideally, would have support for "HEAD" (HEAD being the default when the argument is omitted).
Tinkering with the idea of a "previous", which would allow you to revert without having to find the previous revision's hash. But, "previous" is ambiguous. Previous revision or previous deployed commit? In the case of previous revision, it'd be easy. But what if a guy made 50 revisions since the last deployment, then deploys them all? Then "previous" would revert one revision, but leave the other 49 revisions. Pretty stupid, IMHO.
So, it is my opinion that the previous deployed revision should be stored in a PREVIOUS_REVISION file, along with the REVISION file. That file would allow doing
git-deploy-php [deploy-file] previous, and easily revert to the previously deployed revision. So if you deploy something that breaks your production website website,git-deploy-php production previouswould fix it. Pretty neat. :D