On 2009-01-10, <4jxDQ6FQee2H@xxxxxxxxxx> <4jxDQ6FQee2H@xxxxxxxxxx> wrote: > Our company's website is stored in a GIT Repository. > > 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" ...'). Shouldn't they change it in a sandbox and push it to prod when it gets done instead of directly changing on prod? > 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? If you can enforce no changes directly to prod, you can have the prod server's "master" branch be the one that QA or whatever pushes to (no direct changes on prod). You'd manually (one-time) create a branch called prod_patches where you'd make just the changes needed (port numbers etc as you said). This would be the "checked out" branch. On each push to master, a hook would just "cd wherever; git rebase master"; the port changes would carry over. -- 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
