From: david@lang.hm Date: Sat, 10 Jan 2009 05:58:48 GMT Subject: Re: Git - Pushing to a production website Message-ID: In-Reply-To: <200901092238.06968.bss@iguanasuicide.net> On Fri, 9 Jan 2009, Boyd Stephen Smith Jr. wrote: > On Friday 2009 January 09 22:23:44 4jxDQ6FQee2H@dyweni.com wrote: >> Our company's website is stored in a GIT Repository. > > Interesting. I like the thought. > >> The repository is coded for our test server. When we push updates to >> the production server, have manually run a script to patch several >> files to make the code work on the production server (i.e. port >> numbers, etc). >> >> I'd like to write a script to email me whenever someone changes files >> on the production server without checking those changes back into git >> (i.e. running 'git status | grep "nothing to commit" ...'). >> >> However, this approach get confused by the files patched to work >> correctly. >> >> Is there any way to 'save' those patched files so they don't get >> reported by 'git status', yet not mung up the git history every time >> we push out an update? > > You could simply commit after running the perl script. You could even commit > to a branch so that it's (a little) less likely those changes get integrated > into master. one nice thing about git commit is that if there are no changes it doesn't make a commit. I have a couple files on my desktop (firefox status files for example) that I have a cron job do a commit on every min so that when firefox crashes in a way that can't be recovered by it's 'restore old pages' option I can go back and save things anyway. David Lang