{"thread":{"id":"22780","subject":"Handling non-git config files","startedAt":"2010-02-23T22:52:45Z","lastAt":"2010-03-09T10:50:27Z","messageCount":5,"participants":["Richard Lee","Tim Mazid","Ian Hobson","Jon Seymour","rhlee"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"135487","messageId":"8440EA2C12E50645A68C4AA9887166513FC19C@SERVER.webdezign.local","threadId":"22780","inReplyTo":null,"subject":"Handling non-git config files","fromName":"Richard Lee","fromEmail":"richard@webdezign.co.uk","sentAt":null,"receivedAt":"2010-02-23T22:52:45Z","isPatch":false,"sender":{"key":"richard@webdezign.co.uk","avatar":"https://gravatar.com/avatar/36c0bc285b2d30baa54ed2e1488161fd27a4a4a8128836a673b66204ab08c9b7?d=mp&s=160"},"body":"Hi again git-list,\n\nI have a workflow-related query.\n\nI understand that git is for source code mangement. However in certains\napplications like web applications in a live environment, it ends up\nstoring data related to the state of the application as well.\n\nI myself am a web developer and for me git ends up storing data like the\nroot path of the web app. I would like to work on a test rig, commit and\npush the changes to a central repo. Then pull the changes on to the live\nserver. Having different config files on the test and live deployments\nmake this workflow difficult as I don't know how to tell git to handle\nthe different config files. I have managed to do this with patches, but\nI do not thing it is good in the long run.\n\nI would put the config data in it's own location, but unfortunately I\nhave been given a product to work with and I cannot do that. This means\nthat config data that I do wish to commit is in the same file as data\nthat would vary from deployment to deployment.\n\nCurrently I only work on the live server with git. Firstly this is not\nideal to experiment on a live site. Secondly my colleagues now want to\nlearn git and you can't have several people performing git operations on\nthe same working directory.\n\nSo my quesstion is that is there any way to have several checked out\ncopies of a git repo each with their own slightly different config\nfiles, yet still being able to perform git operations with respect to a\ncentralised repository as if they were identical?\n\nI've thought about using a migration script for each target deployment\nand then ignoring any changes related to the deployment. I've also\nconsidered having each deployment as a seperate branch and then rebasing\nchanges back and forth. However this seems uneccesarily complicated and\nI teaching git beginners about rebasing doesn't seem like a good idea.\n\nThe first solution give a me a corrolary question. I use tig for staging\nchanges. In the config file, the lines specific to the deployment can\nend up in the same hunk as lines specific to the application that I do\nwant to keep. Can I stage partial hunks in tig? Or do I have to use git\nadd --interative?\n\nRegards,\n\nRichard\n"},{"id":"135514","messageId":"SNT124-W237D02A0994F2AEEBDB460C4410@phx.gbl","threadId":"22780","inReplyTo":"8440EA2C12E50645A68C4AA9887166513FC19C@SERVER.webdezign.local","subject":"RE: Handling non-git config files","fromName":"Tim Mazid","fromEmail":"timmazid@hotmail.com","sentAt":"2010-02-24T01:46:41Z","receivedAt":"2010-02-24T01:46:41Z","isPatch":false,"sender":{"key":"timmazid@hotmail.com","avatar":null},"body":"\nHey Richard,\n \nI am by no means an expert, or the sharpest knife in the drawer, for that matter, but let me see if I can understand what you're trying to do.\n\n\n> I understand that git is for source code mangement. However in certains\n> applications like web applications in a live environment, it ends up\n> storing data related to the state of the application as well.\n\nDo you mean that your app creates a file like 'users.dat' or similar that you do not wish to track with git? If so, you can simply not add it the repo, and add it to your .gitignore file.\n \n \n> I myself am a web developer and for me git ends up storing data like the\n> root path of the web app. I would like to work on a test rig, commit and\n> push the changes to a central repo. Then pull the changes on to the live\n> server. Having different config files on the test and live deployments\n> make this workflow difficult as I don't know how to tell git to handle\n> the different config files. I have managed to do this with patches, but\n> I do not thing it is good in the long run.\n\nOnce again, do you need to track the file that stores this data with git?\nOne (probably not very elegant) solution might be to store all location independant data in one config file, to be tracked by git, and a script generated \"local\" config file ignored by git.\n \n \n> I would put the config data in it's own location, but unfortunately I\n> have been given a product to work with and I cannot do that. This means\n> that config data that I do wish to commit is in the same file as data\n> that would vary from deployment to deployment.\n\nWell, that just killed my previous idea. But is there no possibility at all of editing the code to achieve that?\nUnfortunately, I do not believe git can ignore half a file.\n \n \n> Currently I only work on the live server with git. Firstly this is not\n> ideal to experiment on a live site. Secondly my colleagues now want to\n> learn git and you can't have several people performing git operations on\n> the same working directory.\n\nWell, you COULD have multiple people working in the same working directory, but that will present all the usual problems of multiple access to a single file (not very fun at all.)\nWhy not just have them clone their own copy of the repo?\n \n\n> So my quesstion is that is there any way to have several checked out\n> copies of a git repo each with their own slightly different config\n> files, yet still being able to perform git operations with respect to a\n> centralised repository as if they were identical?\n\nBy checked out do you mean a 'git clone'? If so, yes, you can have as many as you want. That is (I think) one of the major points of git.\n \n \n> I've thought about using a migration script for each target deployment\n> and then ignoring any changes related to the deployment. I've also\n> considered having each deployment as a seperate branch and then rebasing\n> changes back and forth. However this seems uneccesarily complicated and\n> I teaching git beginners about rebasing doesn't seem like a good idea.\n\nThe branches for deployments could work. I see no need for rebasing, though. You merely add deployment-specific changes to those branches, and all other changes to your main branch, which you then merge into the deployment-specific branches.\nUnless I've missed something, which is likely, that should work just fine.\n \n \n> The first solution give a me a corrolary question. I use tig for staging\n> changes. In the config file, the lines specific to the deployment can\n> end up in the same hunk as lines specific to the application that I do\n> want to keep. Can I stage partial hunks in tig? Or do I have to use git\n> add --interative?\n\nUnfortunately, I do not know tig and cannot comment on that. I do know, however, that git gui allows you to stage content by hunks, and even line by line, which I often find useful. Is there any reason you are unable/unwilling to use git gui?\n \n \nAll in all, quite a useless reply, but hopefully you will elaborate further as to the data file situation (which is your major concern, unless I'm mistaken, but requires a little more explanation as to why structural changes cannot be made), which can assist someone knowledgable work this out.\n \n \nRegards,\nTim. \t\t \t   \t\t  \n_________________________________________________________________\nFind a great deal on your next car. Get straight to the Point.\nhttp://clk.atdmt.com/NMN/go/157637060/direct/01/"},{"id":"135595","messageId":"4B856FA6.4050808@ianhobson.co.uk","threadId":"22780","inReplyTo":"8440EA2C12E50645A68C4AA9887166513FC19C@SERVER.webdezign.local","subject":"Re: Handling non-git config files","fromName":"Ian Hobson","fromEmail":"ian@ianhobson.co.uk","sentAt":"2010-02-24T18:27:50Z","receivedAt":"2010-02-24T18:27:50Z","isPatch":false,"sender":{"key":"ian@ianhobson.co.uk","avatar":null},"body":"Richard Lee wrote:\n> So my quesstion is that is there any way to have several checked out\n> copies of a git repo each with their own slightly different config\n> files, yet still being able to perform git operations with respect to a\n> centralised repository as if they were identical?\n>\n>   \nHi Richard,\n\nYes. They are called branches :)\n\nWhat I do is have a branch for each version that I need.\n\nTo fix a problem I checkout master, make the repair, and commit.\n\nThen to deploy that change I perform three steps (for each production \nversion).\n\ngit checkout <clientBranch>\ngit rebase master\nrsync to the production server (ignoring .git and temp files)\n\nAll the differences between versions - config files, images, logos, etc \n- are all included in the GIT,\nrepo and I don't have to worry about them. To set up the branches, I \nsimply checked out a new branch for each and applied the changes for \nthat production version, and committed. It works very well in practise. \n(Do take care to checkout the version you want to work on before you \nstart work, or you may have to lose your work to recover!).\n\nIan\n"},{"id":"135616","messageId":"2cfc40321002241337q6b437803m82d05fb272cca6b2@mail.gmail.com","threadId":"22780","inReplyTo":"8440EA2C12E50645A68C4AA9887166513FC19C@SERVER.webdezign.local","subject":"Re: Handling non-git config files","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2010-02-24T21:37:53Z","receivedAt":"2010-02-24T21:37:53Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"[ Richard sent his own copy ]\n\nI have used git in a deployment scenario and found it to be very useful.\n\nThe way I dealt with this problem was to treat the variants as a build\nproblem. During the build, I create a version of the deployment\nartifacts that reflect a generic, uncustomized server. This gets\nchecked into a branch. To build the an environment specific variant, I\ncheckout the build result for the uncustomized server on a new branch,\ncustomize it and commit that to the tip of the environment specfic\nbranch. The process continues down the hierarchy, so I take the\nenvironment specific variant, customize it for particular servers and\ncommit that to a new branch. Each branch is represented in git as a\nmerge of the current build with the results of the previous build for\nthe previous for the same branch. [ Thereby allowing FF merges during\ndeployment ]\n\nThe end result is that I have a git repo with one branch for the\nabstract server, one for each environment (all uncustomized or\npartially customized) and one full customized branch for each physical\nserver. The whole repo can then be pushed to all environments (but not\ncheckout there). Deployment is then simply a question of pulling (or\nchecking out) the right tag of the right branch on each server at the\nright time (e.g. after testing, during change windows etc).\n\nPulling has the advantage of preserving adhoc configuration changes in\ndeployed environments that have not been folded back into the build\nprocess, though at some risk of merge conflicts &/or inconsistency. My\napproach in the case of merge conflicts was to report the problem,\nsave the current state (in the git history) and resolve in favour of\nthe build product. Alternative strategies might be to abort the\ndeployment until the conflict is resolved, etc.\n\n(I also used a separate aggregation technique to aggregate several\ndistinct repo into a single hub repo so that as to minimise the number\nof git operations required to sync two nodes in the deployment\ntopology.)\n\nUsing git in this way was great - deployment of an incremental release\nwas super quick because the repos could be pre-deployed and transfers\ntypically only included files that had changed for the release - gone\nare the big tar balls being transferred that contain mostly unchanged\nstuff.\n"},{"id":"136449","messageId":"1268131827388-4701369.post@n2.nabble.com","threadId":"22780","inReplyTo":"2cfc40321002241337q6b437803m82d05fb272cca6b2@mail.gmail.com","subject":"Re: Handling non-git config files","fromName":"rhlee","fromEmail":"richard@webdezign.co.uk","sentAt":"2010-03-09T10:50:27Z","receivedAt":"2010-03-09T10:50:27Z","isPatch":false,"sender":{"key":"richard@webdezign.co.uk","avatar":"https://gravatar.com/avatar/36c0bc285b2d30baa54ed2e1488161fd27a4a4a8128836a673b66204ab08c9b7?d=mp&s=160"},"body":"\nGit-list,\n\nThanks to Jon, Ian and Tim for your replies.\n\nI was reading Jon's reply and the workflow he uses seems to fit my purpose.\nTo migrate an application, you would branch it, set any local configuration\nand commit. To bring over any changes you would just merge them over. This\nwould leave any deployment artifacts (a great term to describe local\nchanges) intact.\n\nI have only been using branching and merging since November, when I was\ninstructed how to do so by git-list. I realise now that this is just basic\nbranching and merging. The workflow described will work with any SCM\nsoftware that supports branching and merging.\n\nRichard\n-- \nView this message in context: http://n2.nabble.com/Handling-non-git-config-files-tp4622419p4701369.html\nSent from the git mailing list archive at Nabble.com.\n"}]}