On 5/4/2012 11:10 PM, Marc Weber wrote:
I always did "git pull" on the servers - but the history of my projects
is not that huge.. Thus I never cared.
Great: You can keep some server specific config settings and rebase
them -
So I could rebase apache virtual host conf files with generic template
changes like symlink support, but keep the networking ip's. Merge
conflicts would be bad. I guess that would be cause to reset --hard to
a previous commit.
and you can do a fast git status to check whether file contents
have been modified (eg determine whether you've been hacked ..)
With 'source is run' like html, css, etc. that would be a good way to
enforce no-hacking-allowed support agreements.
If you really care that much about history why not push a zip file using
git archive --format=zip and unpack that on the deployment server
instead?
That is what I'm currently doing. By paying attention to tracked
executable bits I don't even have to fix permissions on deployment.
The scriptable patching of a git repo (scripted checkout of remote
tracking branch commits to worktree with inserted conversions and
validations -- an interactive cherry-pick so to speak) allows for
flexible conversions of varying patch levels. Maybe git-sequencer will
do this when it comes out.
Also, I could have a deployment tracking repo on one of my servers that
remotes to all deployed servers and pulls to refresh my monitor view of
all deployed revisions in gitk.
For FTP access only this did a great job for small projects:
https://github.com/MarcWeber/git-ftp (-> git-ftp-minimal.sh)
It only copies changed files *and* checks whether they have been
modified on the server first (detecting work of others).
But that's probably not a good thing for automatic deployment.
I'll take a look to see what I can steal, uh I mean reuse. Thanks!
v/r,
neal
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html