Re: git for pushing local subdir to website

[Matt Di Pasquale <pasquale@fas.harvard.edu>]

wow. thanks. that gave me some good ideas.
i think u were right about rsync. it was pretty easy to set up.
assuming the name of my app is myapp, i just put the following alias
in my ~/.bash_profile on my local machine.

alias mapush='rsync -e ssh -av --exclude=".DS_Store"
~/Projects/myapp/myapp.com/
matt@mattdipasquale.com:projects/myapp.com/'

btw, is there a way to make aliases that are local to certain
directories? like typing mapush works from any directory. what if i
just wanted the alias to be push and only work from within
~/Projects/myapp? is that possible?

those aren't the actual paths i used. but u get the point.
then i just type mapush and it does it.

and i just use a local git repository in ~/Projects/myapp/.git to
track local changes since none are made on the server... so i don't
need a git repo there like u said...

it's pretty fast. but will rsync be okay if i decide to move files
around a bit? i know git is pretty good about that. and what if i
delete certain files? will rsync delete them... like git does? guess
i'll figure those questions out in time.

thanks!

-matt


On Mon, Aug 3, 2009 at 2:58 PM, Wesley J. Landaker<wjl@icecavern.net> wrote:
> On Monday 03 August 2009 12:09:26 Matt Di Pasquale wrote:
>> yes... i've thought of that. that's a good idea. i just love git and
>> i've never really used rsync. how do i do that?
>> i'll go google it..
>
> Rsync can do a lot of things, but the usual easy way to do it is to do
> something like this to send files via rsync over an ssh connection:
>
> rsync -av /some_dir/ user@host:/some_dir/
>
> This is essentially the same as using scp, but rsync saves a lot of network
> bandwidth by only sending the changes between the source and destination.
>
>> i guess it would also be nice to use git though incase i decide i want
>> a collaborator, right?
>
> Setting things up to have a collaboration is kind of orthogonal to
> installing a production version of your app, but you could use the same
> server (and possibly the same git repository) for both things if you wanted
> to.
>
> Here an example of one way to do it:
>
> On the server you could have a normal git repository in, say,
> /home/me/myapp, and it always has the "production" branch checked out. So
> now the following directories are interesting:
>
> /home/me/myapp              -- repository branch w/ "production" checked out
> /home/me/myapp/.git         -- the actual bare git repository
> /home/me/myapp/example.com/ -- the files that the web server should see
>
> Now, you can use symlinks (or web-server configuration) to point the
> webserver to the right locations, for example:
>
> http://example.com/myapp/     -- link to /home/me/myapp/example.com/
> http://example.com/myapp.git/ -- link to /home/me/myapp/.git/
>
> Now, collaborators can pull from the http://example.com/myapp.git and get
> the whole project, but access to http://example.com/myapp/ sees the
> example.com subdir as it's root, and everything works normally (assuming
> webserver configuration & permissions are correct).
>
> Now you work on whatever branches you want, and push to the server whenever
> you want for collaboration using whatever branches you want. As far as the
> webserver is concerned, nothing changes when you do a push.
>
> Then, when you are ready to change the website, you put your production
> changes on the "production" branch, push them, and make sure they are
> checked out on the server (git push doesn't automatically check out the
> files), e.g.:
>
> client$ # just made changes in production branch and want them "live"
> client$ git push
>
> server$ cd /home/me/myapp
> server$ git reset --hard
>
>> how would u set it up?
>
> Personally, I might set something like this if I had a good reason, but
> otherwise, I'd host my git repository for collaboration separately, and just
> use rsync to install production files on the server. For one thing, that
> needs less prerequisites and setup on the server, so it's good if you don't
> fully control the server.
>
> Either way, a "production" branch is a good idea so you know logically
> exactly what and when you released things live.
>