{"thread":{"id":"21492","subject":"suggestions for local configs?","startedAt":"2009-11-06T03:11:42Z","lastAt":"2009-11-06T07:21:39Z","messageCount":2,"participants":["Tim Rupp","Johannes Sixt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"126947","messageId":"4AF393EE.4030205@gmail.com","threadId":"21492","inReplyTo":null,"subject":"suggestions for local configs?","fromName":"Tim Rupp","fromEmail":"caphrim007@gmail.com","sentAt":"2009-11-06T03:11:42Z","receivedAt":"2009-11-06T03:11:42Z","isPatch":false,"sender":{"key":"caphrim007@gmail.com","avatar":null},"body":"Hi list, I'm wrestling with a question and figured that someone on the\nlist may have some suggestions that have worked for them.\n\nI have a piece of software that has default and local configuration\nfiles. The default files ship with the tarball. The local files are\ncopied over from the default folder during installation and can be\nmodified for a particular install.\n\nI clone my source repo on my test and prod systems, but have gotten in\nthe bad habit of versioning the local configuration files. My (albeit\npathetic) excuse is that when I test the code I may accidentally dork\nwith the local config files and need to revert back to the correct ones.\n\nAt the same time though, I do want to version said local configs in\nsomething so that if changes are made and they need to be backed out, it\ncan be done and there is the commit log that keeps track of what changed.\n\nSo the question is\n\n- Can anyone suggest good ways of setting up git to track both the code\nand local configs without making a whole new repository (code repo and\ncode config repo)\n\nIf not, any other suggestions are welcome and I'll consider how best to\nmake them work in my environment.\n\nI've briefly skimmed through the pro git book online and considered sub\nmodules and sub-tree merging, but the kicker is that I may need to push\nthe whole kit-n-kaboodle master repo to remote git servers and those two\napproaches sound hairy.\n\nAny help is appreciated.\n\nThanks,\nTim\n"},{"id":"126956","messageId":"4AF3CE83.1060400@viscovery.net","threadId":"21492","inReplyTo":"4AF393EE.4030205@gmail.com","subject":"Re: suggestions for local configs?","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2009-11-06T07:21:39Z","receivedAt":"2009-11-06T07:21:39Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Tim Rupp schrieb:\n> I have a piece of software that has default and local configuration\n> files. The default files ship with the tarball. The local files are\n> copied over from the default folder during installation and can be\n> modified for a particular install.\n\nThis is how *I* would organize it, but it is a bit overengineered if the\nchanges needed in the configuration are only minimal:\n\n  ---o--o--X1--o--o--X2--o          master (aka upstream)\n      \\     \\             \\\n       R-----M1------------M3       rename\n        \\     \\             \\\n         Y-----M2------------M4     production\n\nWe need two branches in addition to master, which tracks upstream version.\n\n1. The first branch *renames* the example configuration to the effective\nconfiguration:\n\n   git mv foo.conf.example foo.conf\n   # commit R\n   git commit -m \"Use the example configuration\"\n\nIt is important that *no change* is made to the configuration file, and it\nfurthermore assumes that the production configuration (foo.conf) does not\nexist [*].\n\nThe point of this commit is that git can determine that the file was\nrenamed with 100% similarity.\n\n2. The second branch is actually where the customization happens, this is\ncommit Y:\n\n   git checkout production\n   edit foo.conf\n   # commit Y\n   git commit -m \"configuration changes needed in production\"\n\n\nAssume, upstream made changes to the configuration (commit X1). These\nchanges are merged in the following way:\n\n1.  git checkout rename && git merge master\n\nThis creates M1. git detects that on our side the file was renamed, and\nmerges the upstream changes into the renamed file. Since we didn't modify\nthe file in R, there are no conflicts.\n\n2.  git checkout production && git merge rename\n\nThis creates M2. This is a regular merge that integrates upstream changes\nwith the local changes made in Y, possibly with conflicts.\n\nYou repeat the procedure when upstream makes more changes to the example\nconfiguration in X2. This time, git merge again detects that the file was\nrenamed with 100% similarity, and things work just like with M1 and M2.\n\n[*] If there is a configuration file in addition to the example\nconfiguration, another branch is needed that removes it.\n\n-- Hannes\n"}]}