{"thread":{"id":"17073","subject":"Git - Pushing to a production website","startedAt":"2009-01-10T04:23:44Z","lastAt":"2009-01-10T11:50:01Z","messageCount":10,"participants":["4jxdq6fqee2h@dyweni.com","Boyd Stephen Smith Jr.","david@lang.hm","Jacob Helwig","David Aguilar","Sitaram Chamarty"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"99851","messageId":"20090109222344.3539138a@family.dyweni.com","threadId":"17073","inReplyTo":null,"subject":"Git - Pushing to a production website","fromName":"","fromEmail":"4jxdq6fqee2h@dyweni.com","sentAt":"2009-01-10T04:23:44Z","receivedAt":"2009-01-10T04:23:44Z","isPatch":false,"sender":{"key":"4jxdq6fqee2h@dyweni.com","avatar":null},"body":"Hi,\n\nOur company's website is stored in a GIT Repository.\n\nThe repository is coded for our test server.  When we push updates to\nthe production server, have manually run a script to patch several\nfiles to make the code work on the production server (i.e. port\nnumbers, etc).\n\nI'd like to write a script to email me whenever someone changes files\non the production server without checking those changes back into git\n(i.e. running 'git status | grep \"nothing to commit\" ...').\n\nHowever, this approach get confused by the files patched to work\ncorrectly.\n\nIs there any way to 'save' those patched files so they don't get\nreported by 'git status', yet not mung up the git history every time\nwe push out an update?\n\nThanks!\n"},{"id":"99852","messageId":"200901092238.06968.bss@iguanasuicide.net","threadId":"17073","inReplyTo":"20090109222344.3539138a@family.dyweni.com","subject":"Re: Git - Pushing to a production website","fromName":"Boyd Stephen Smith Jr.","fromEmail":"bss@iguanasuicide.net","sentAt":"2009-01-10T04:38:06Z","receivedAt":"2009-01-10T04:38:06Z","isPatch":false,"sender":{"key":"bss@iguanasuicide.net","avatar":"https://gravatar.com/avatar/84b95eeff194b816c1568b1339e63e4b229825298664a9037b9f1ec713ead1e3?d=mp&s=160"},"body":"On Friday 2009 January 09 22:23:44 4jxDQ6FQee2H@dyweni.com wrote:\n>Our company's website is stored in a GIT Repository.\n\nInteresting.  I like the thought.\n\n>The repository is coded for our test server.  When we push updates to\n>the production server, have manually run a script to patch several\n>files to make the code work on the production server (i.e. port\n>numbers, etc).\n>\n>I'd like to write a script to email me whenever someone changes files\n>on the production server without checking those changes back into git\n>(i.e. running 'git status | grep \"nothing to commit\" ...').\n>\n>However, this approach get confused by the files patched to work\n>correctly.\n>\n>Is there any way to 'save' those patched files so they don't get\n>reported by 'git status', yet not mung up the git history every time\n>we push out an update?\n\nYou could simply commit after running the perl script.  You could even commit \nto a branch so that it's (a little) less likely those changes get integrated \ninto master.\n-- \nBoyd Stephen Smith Jr.                     ,= ,-_-. =. \nbss@iguanasuicide.net                     ((_/)o o(\\_))\nICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' \nhttp://iguanasuicide.net/                      \\_/     \n"},{"id":"99853","messageId":"20090109224618.5d8c461c@family.dyweni.com","threadId":"17073","inReplyTo":"200901092238.06968.bss@iguanasuicide.net","subject":"Re: Git - Pushing to a production website","fromName":"","fromEmail":"4jxdq6fqee2h@dyweni.com","sentAt":"2009-01-10T04:46:18Z","receivedAt":"2009-01-10T04:46:18Z","isPatch":false,"sender":{"key":"4jxdq6fqee2h@dyweni.com","avatar":null},"body":"\n> You could simply commit after running the perl script.  You could\n> even commit to a branch so that it's (a little) less likely those\n> changes get integrated into master.\n\nHow about this, ran by the post-update hook:\n\n\nFor the first update:\n\n - Do a git pull\n - Then create a new branch 'working' and checkout\n - Apply the patches to 'working' and commit\n\nThis leaves 'working' == 'master^'\n\nFor subsequent updates:\n - Compare the SHA1 hashes for 'working' and 'master^'.\n   - If they don't match, throw an error and exit\n - Assuming they match, checkout 'master' and delete 'working'\n - Do a git pull\n - Then create a new branch 'working' and checkout\n - Apply the patches to 'working' and commit\n\n\nThis would keep the working directory clean and allow future updates to\noccur, if no one commits anything to git 'working'.  If they did, the\nscript would exit and prevent the update requiring the developer to\nreview the commit logs and cherry-pick where necessary.\n"},{"id":"99855","messageId":"200901092304.51986.bss@iguanasuicide.net","threadId":"17073","inReplyTo":"20090109224618.5d8c461c@family.dyweni.com","subject":"Re: Git - Pushing to a production website","fromName":"Boyd Stephen Smith Jr.","fromEmail":"bss@iguanasuicide.net","sentAt":"2009-01-10T05:04:47Z","receivedAt":"2009-01-10T05:04:47Z","isPatch":false,"sender":{"key":"bss@iguanasuicide.net","avatar":"https://gravatar.com/avatar/84b95eeff194b816c1568b1339e63e4b229825298664a9037b9f1ec713ead1e3?d=mp&s=160"},"body":"On Friday 2009 January 09 22:46:18 4jxDQ6FQee2H@dyweni.com wrote:\n>> You could simply commit after running the perl script.  You could\n>> even commit to a branch so that it's (a little) less likely those\n>> changes get integrated into master.\n>\n>How about this, ran by the post-update hook:\n>\n>For the first update:\n>\n> - Do a git pull\n\nI'm not enitirely sure you want post-update doing the pull.\n\n> - Then create a new branch 'working' and checkout\n> - Apply the patches to 'working' and commit\n>\n>This leaves 'working' == 'master^'\n\nActually, it leaves HEAD == working and master == working^.\n\n>For subsequent updates:\n> - Compare the SHA1 hashes for 'working' and 'master^'.\n>   - If they don't match, throw an error and exit\n> - Assuming they match, checkout 'master' and delete 'working'\n> - Do a git pull\n\n(See above)\n\n> - Then create a new branch 'working' and checkout\n> - Apply the patches to 'working' and commit\n>\n>\n>This would keep the working directory clean and allow future updates to\n>occur, if no one commits anything to git 'working'.  If they did, the\n>script would exit and prevent the update requiring the developer to\n>review the commit logs and cherry-pick where necessary.\n\nIt wouldn't *completely* prevent changes to working as one could \"git \ncommit --amend\" and still have working^ == master.  That said, if developers \nget creative enough they can probably bypass most measures, at least those \nbased on a hook.\n\nA privileged process for updates could stash the expected SHA for master and \nworking somewhere developers can't write.  That should prevent even dedicated \ndevelopers from making unauthorized changes, modulo security/cryptographic \nexploits.\n-- \nBoyd Stephen Smith Jr.                     ,= ,-_-. =. \nbss@iguanasuicide.net                     ((_/)o o(\\_))\nICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' \nhttp://iguanasuicide.net/                      \\_/     \n"},{"id":"99856","messageId":"20090109233037.31198694@family.dyweni.com","threadId":"17073","inReplyTo":"200901092304.51986.bss@iguanasuicide.net","subject":"Re: Git - Pushing to a production website","fromName":"","fromEmail":"4jxdq6fqee2h@dyweni.com","sentAt":"2009-01-10T05:30:37Z","receivedAt":"2009-01-10T05:30:37Z","isPatch":false,"sender":{"key":"4jxdq6fqee2h@dyweni.com","avatar":null},"body":"> > - Do a git pull  \n> \n> I'm not enitirely sure you want post-update doing the pull.\n\nReally?\n\nLet's say the website lives in /srv/www/htdocs\nLet's also say the git repository lives in /srv/www/git\n\nAll developers pull/push from /srv/www/git  (git@server:/srv/www/git)\n\nThe website is a clone of /srv/www/git and only tracks 'master'.\nPost-update (simplified) changes to /srv/www/htdocs and does 'git pull'.\n\nI'm referencing this article:\n  http://jblevins.org/log/tools/managing-websites-with-git\n\nWould you recommend a different way to automatically push any changes\nto 'master' down to the website?\n\n\n\n> \n> > - Then create a new branch 'working' and checkout\n> > - Apply the patches to 'working' and commit\n> >\n> >This leaves 'working' == 'master^'  \n> \n> Actually, it leaves HEAD == working and master == working^.\n\nI'm sorry - I mixed up my terminology.\n\nI am referring to the branch's log.\n\n'working' has 1 more log entry than 'master'.\n\nExample:\n - git log master | grep ^commit | tail -n 2 | head -n 1\n - git log working | grep ^commit | tail -n 1 | head -n 1\n\nBoth of these commands should return the same commit hash.\n"},{"id":"99857","messageId":"200901092354.16973.bss@iguanasuicide.net","threadId":"17073","inReplyTo":"20090109233037.31198694@family.dyweni.com","subject":"Re: Git - Pushing to a production website","fromName":"Boyd Stephen Smith Jr.","fromEmail":"bss@iguanasuicide.net","sentAt":"2009-01-10T05:54:16Z","receivedAt":"2009-01-10T05:54:16Z","isPatch":false,"sender":{"key":"bss@iguanasuicide.net","avatar":"https://gravatar.com/avatar/84b95eeff194b816c1568b1339e63e4b229825298664a9037b9f1ec713ead1e3?d=mp&s=160"},"body":"On Friday 09 January 2009, 4jxDQ6FQee2H@dyweni.com wrote about 'Re: Git - \nPushing to a production website':\n>> > - Do a git pull\n>>\n>> I'm not enitirely sure you want post-update doing the pull.\n>\n>Let's say the website lives in /srv/www/htdocs\n>Let's also say the git repository lives in /srv/www/git\n>\n>All developers pull/push from /srv/www/git  (git@server:/srv/www/git)\n>\n>The website is a clone of /srv/www/git and only tracks 'master'.\n>Post-update (simplified) changes to /srv/www/htdocs and does 'git pull'.\n\nAh.  I was assuming you were \"git pull\"ing in the repository that the hook \nwas running from.  In this case you are \"git pull\"ing in a different \nrepository, which should be fine.\n\n>> >This leaves 'working' == 'master^'\n>>\n>> Actually, it leaves HEAD == working and master == working^.\n>\n>I'm sorry - I mixed up my terminology.\n>\n>I am referring to the branch's log.\n>\n>'working' has 1 more log entry than 'master'.\n\nYes, which means working^ == master.\n\ncommit-ish^ means the first parent of commit-ish\ncommit-ish^2 means the second parent of commit-ish\ncommit-ish~2 means the \"first grandparent\" of commit-ish\n\n>Example:\n> - git log master | grep ^commit | tail -n 2 | head -n 1\n> - git log working | grep ^commit | tail -n 1 | head -n 1\n>\n>Both of these commands should return the same commit hash.\n\nAs would:\n- git rev-parse master\n- git rev-parse working^\n-- \nBoyd Stephen Smith Jr.                     ,= ,-_-. =. \nbss@iguanasuicide.net                     ((_/)o o(\\_))\nICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' \nhttp://iguanasuicide.net/                      \\_/     \n"},{"id":"99854","messageId":"alpine.DEB.1.10.0901092157110.31038@asgard.lang.hm","threadId":"17073","inReplyTo":"200901092238.06968.bss@iguanasuicide.net","subject":"Re: Git - Pushing to a production website","fromName":"","fromEmail":"david@lang.hm","sentAt":"2009-01-10T05:58:48Z","receivedAt":"2009-01-10T05:58:48Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Fri, 9 Jan 2009, Boyd Stephen Smith Jr. wrote:\n\n> On Friday 2009 January 09 22:23:44 4jxDQ6FQee2H@dyweni.com wrote:\n>> Our company's website is stored in a GIT Repository.\n>\n> Interesting.  I like the thought.\n>\n>> The repository is coded for our test server.  When we push updates to\n>> the production server, have manually run a script to patch several\n>> files to make the code work on the production server (i.e. port\n>> numbers, etc).\n>>\n>> I'd like to write a script to email me whenever someone changes files\n>> on the production server without checking those changes back into git\n>> (i.e. running 'git status | grep \"nothing to commit\" ...').\n>>\n>> However, this approach get confused by the files patched to work\n>> correctly.\n>>\n>> Is there any way to 'save' those patched files so they don't get\n>> reported by 'git status', yet not mung up the git history every time\n>> we push out an update?\n>\n> You could simply commit after running the perl script.  You could even commit\n> to a branch so that it's (a little) less likely those changes get integrated\n> into master.\n\none nice thing about git commit is that if there are no changes it doesn't \nmake a commit.\n\nI have a couple files on my desktop (firefox status files for example) \nthat I have a cron job do a commit on every min so that when firefox \ncrashes in a way that can't be recovered by it's 'restore old pages' \noption I can go back and save things anyway.\n\nDavid Lang\n"},{"id":"99859","messageId":"8c9a060901092241y23e56cbbr6aa7f322afaa2f6b@mail.gmail.com","threadId":"17073","inReplyTo":"20090109222344.3539138a@family.dyweni.com","subject":"Re: Git - Pushing to a production website","fromName":"Jacob Helwig","fromEmail":"jacob.helwig@gmail.com","sentAt":"2009-01-10T06:41:54Z","receivedAt":"2009-01-10T06:41:54Z","isPatch":false,"sender":{"key":"jacob.helwig@gmail.com","avatar":"https://avatars.githubusercontent.com/u/14557?v=4"},"body":"On Fri, Jan 9, 2009 at 20:23,  <4jxDQ6FQee2H@dyweni.com> wrote:\n> Hi,\n>\n> Our company's website is stored in a GIT Repository.\n>\n> The repository is coded for our test server.  When we push updates to\n> the production server, have manually run a script to patch several\n> files to make the code work on the production server (i.e. port\n> numbers, etc).\n>\n\nAre these all static pages?  If they're Perl/PHP/Ruby/whatever, why\nnot add tests for the Live vs. Dev?  Check for an environment\nvariable, or a file on disk, etc, etc?  That way any checks described\nbelow won't get \"confused\" by the (no longer necessary) patches, and\nyou won't have to worry about rebasing commits, and any potential\nconflicts there.\n\n> I'd like to write a script to email me whenever someone changes files\n> on the production server without checking those changes back into git\n> (i.e. running 'git status | grep \"nothing to commit\" ...').\n>\n> However, this approach get confused by the files patched to work\n> correctly.\n>\n> Is there any way to 'save' those patched files so they don't get\n> reported by 'git status', yet not mung up the git history every time\n> we push out an update?\n>\n> Thanks!\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n>\n"},{"id":"99870","messageId":"402731c90901100304w2ed740e0gdcb41381a41a7f5d@mail.gmail.com","threadId":"17073","inReplyTo":"20090109222344.3539138a@family.dyweni.com","subject":"Re: Git - Pushing to a production website","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2009-01-10T11:04:17Z","receivedAt":"2009-01-10T11:04:17Z","isPatch":false,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On Fri, Jan 9, 2009 at 8:23 PM,  <4jxDQ6FQee2H@dyweni.com> wrote:\n> Hi,\n>\n> Our company's website is stored in a GIT Repository.\n>\n> The repository is coded for our test server.  When we push updates to\n> the production server, have manually run a script to patch several\n> files to make the code work on the production server (i.e. port\n> numbers, etc).\n\nThe simplest solution is to not track those files at all.\nInstead of tracking app.conf, mv it to app.conf.sample\nand track that instead.  Likewise, add an entry for app.conf\nin .gitignore.\n\nWhen devs create new sandboxes they just\n        cp app.conf.sample app.conf\nand all is well because app.conf is in .gitignore.\n\nIf you literally do 'git mv' in a sandbox and push it out then\nbe careful since pushing that change to production will do\nexactly what it was told to do (remove the config).\nit's a small price to pay for simplicity, though, so just\nremember to keep a backup.\n\n\n> I'd like to write a script to email me whenever someone changes files\n> on the production server without checking those changes back into git\n> (i.e. running 'git status | grep \"nothing to commit\" ...').\n\nHaving the config files in .gitignore eliminates a lot of work in\nyour update hooks and it makes writing this script much easier.\n\nThe only extra cost comes in having to manage the config files\nseparately from the application, but it's nothing that can't be\nautomated.\n\n\n> However, this approach get confused by the files patched to work\n> correctly.\n>\n> Is there any way to 'save' those patched files so they don't get\n> reported by 'git status', yet not mung up the git history every time\n> we push out an update?\n>\n> Thanks!\n> --\n\n\n-- \n    David\n"},{"id":"99878","messageId":"slrngmh2r9.vur.sitaramc@sitaramc.homelinux.net","threadId":"17073","inReplyTo":"20090109222344.3539138a@family.dyweni.com","subject":"Re: Git - Pushing to a production website","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2009-01-10T11:50:01Z","receivedAt":"2009-01-10T11:50:01Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On 2009-01-10, <4jxDQ6FQee2H@dyweni.com> <4jxDQ6FQee2H@dyweni.com> wrote:\n\n> Our company's website is stored in a GIT Repository.\n>\n> The repository is coded for our test server.  When we push updates to\n> the production server, have manually run a script to patch several\n> files to make the code work on the production server (i.e. port\n> numbers, etc).\n>\n> I'd like to write a script to email me whenever someone changes files\n> on the production server without checking those changes back into git\n> (i.e. running 'git status | grep \"nothing to commit\" ...').\n\nShouldn't they change it in a sandbox and push it to prod\nwhen it gets done instead of directly changing on prod?\n\n> However, this approach get confused by the files patched to work\n> correctly.\n>\n> Is there any way to 'save' those patched files so they don't get\n> reported by 'git status', yet not mung up the git history every time\n> we push out an update?\n\nIf you can enforce no changes directly to prod, you can have\nthe prod server's \"master\" branch be the one that QA or\nwhatever pushes to (no direct changes on prod).\n\nYou'd manually (one-time) create a branch called\nprod_patches where you'd make just the changes needed (port\nnumbers etc as you said).\n\nThis would be the \"checked out\" branch.\n\nOn each push to master, a hook would just \"cd wherever; git\nrebase master\"; the port changes would carry over.\n"}]}