{"thread":{"id":"29197","subject":"Big Mess--How to use Git to resolve","startedAt":"2011-12-17T12:32:10Z","lastAt":"2011-12-21T23:56:10Z","messageCount":7,"participants":["hs_glw","Randal L. Schwartz","Holger Hellmuth","Neal Kreitzinger","Seth Robertson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"181398","messageId":"1324125130643-7103964.post@n2.nabble.com","threadId":"29197","inReplyTo":null,"subject":"Big Mess--How to use Git to resolve","fromName":"hs_glw","fromEmail":"greg@hra.net","sentAt":"2011-12-17T12:32:10Z","receivedAt":"2011-12-17T12:32:10Z","isPatch":false,"sender":{"key":"greg@hra.net","avatar":null},"body":"I want to use Git, I have had read documentation installed on my local\nmachine, then looked at my mess of code and don't know what the hell to do.\n\nI have a Perl Web Application, several hundred programs, templates,\nconfiguration files.\n\nCompanies buy my application and I host it for them.\n\nI have 40+ clients\n\nEach client has its own unique installation of the software on my web\nserver.\n\nSome clients have customizations of the code, some have version 5 of the\nsoftware others have 5.2, 5.5 etc.\n\nThis sucks.\n\nMy goal is to pull all the different versions in, put them all together, and\ncreate a master version of the software that runs for all clients.\n\nThere will still be some files that are completely unique to each client\n(style sheets and logos for instance).\n\nI can't figure out if I should start with my oldest version of the code or\nthe newest, I haven't really found in the documentation how to start with\ndifferent permutations of the code in a repository.   Everything I have\nfound assumes you start with one set of code, then make changes.  I have\nmultiple variations and need to get them consistent.\n\nI expect to use all of 2012 getting this put back together, but I have to\nstart.  Does anyone have any suggestions on how I should set Git up to do\nwhat I need?\n\n--\nView this message in context: http://git.661346.n2.nabble.com/Big-Mess-How-to-use-Git-to-resolve-tp7103964p7103964.html\nSent from the git mailing list archive at Nabble.com.\n"},{"id":"181401","messageId":"86iplf2oy5.fsf@red.stonehenge.com","threadId":"29197","inReplyTo":"1324125130643-7103964.post@n2.nabble.com","subject":"Re: Big Mess--How to use Git to resolve","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2011-12-17T15:33:06Z","receivedAt":"2011-12-17T15:33:06Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"hs\" == hs glw <greg@hra.net> writes:\n\nhs> Some clients have customizations of the code, some have version 5 of the\nhs> software others have 5.2, 5.5 etc.\n\nCreate an empty repo.\n\nUnpack the oldest release (I presume you still have the tarballs) you\nmight have forked a customer from.  commit it, and tag it as v5.0 (or\nwhatever it is).\n\nIn the same dir, delete the files, and unpack the *next* release.  git\nadd . again, and commit that, effectively recording the changes from one\nrelease to the next.  Tag it v5.1 or whatever.\n\nRepeat for all releases.\n\ngit branch -m master release\n\nThat will remain your untouched release branch.\n\nNow, take customer1.  Figure out which release is closest to their\nmodified code.  Let's say it's v5.2\n\ngit checkout -b customer1 v5.2\n\nerase the files, copy their work in, and commit.  You'll now have a\ncustomer1 branch that comes off the right release.\n\nrepeat for each customer.\n\nSo now you have tags for each release, and every customer's code checked\nin somewhere.\n\nIf you feel brave, you can try to move a customer to a later release:\n\ngit checkout customer1\ngit rebase v5.5\n\nThat will try to apply the diff between v5.2 and customer1 directly to\nthe top of v5.5.  Might fail, might need some mopping up.  But at least\nthe hard work is done.\n\nHope this helps.\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>\nSmalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.\nSee http://methodsandmessages.posterous.com/ for Smalltalk discussion\n"},{"id":"181404","messageId":"1324147247781-7104493.post@n2.nabble.com","threadId":"29197","inReplyTo":"86iplf2oy5.fsf@red.stonehenge.com","subject":"Re: Big Mess--How to use Git to resolve","fromName":"hs_glw","fromEmail":"greg@hra.net","sentAt":"2011-12-17T18:40:47Z","receivedAt":"2011-12-17T18:40:47Z","isPatch":false,"sender":{"key":"greg@hra.net","avatar":null},"body":"Randal, thank you for the comprehensive answer.  I have one follow-up:  we\nhave the working files, then in our installation files we have .PL files\nthat are worked on by some iteration of \"make\" to insert paths both into\n.cgi files and config files, should these installation files be setup as a\nbranch? or is there a more correct way of implementing this?\n\n--\nView this message in context: http://git.661346.n2.nabble.com/Big-Mess-How-to-use-Git-to-resolve-tp7103964p7104493.html\nSent from the git mailing list archive at Nabble.com.\n"},{"id":"181474","messageId":"4EEF6E98.7080000@ira.uka.de","threadId":"29197","inReplyTo":"1324147247781-7104493.post@n2.nabble.com","subject":"Re: Big Mess--How to use Git to resolve","fromName":"Holger Hellmuth","fromEmail":"hellmuth@ira.uka.de","sentAt":"2011-12-19T17:04:24Z","receivedAt":"2011-12-19T17:04:24Z","isPatch":false,"sender":{"key":"hellmuth@ira.uka.de","avatar":null},"body":"On 17.12.2011 19:40, hs_glw wrote:\n> Randal, thank you for the comprehensive answer.  I have one follow-up:  we\n> have the working files, then in our installation files we have .PL files\n> that are worked on by some iteration of \"make\" to insert paths both into\n> .cgi files and config files, should these installation files be setup as a\n> branch? or is there a more correct way of implementing this?\n\nIf I understand you correctly the working aka source files are patched \nin place to adapt to a customer. I would suggest changing that a bit so \nthat the source filename is different from the installation filename. \nAdd the source file into the repo and add the installation filenames \ninto .gitignore\n\nThat way you don't have generated files in the repository. Which is \nusually avoided because they easily get out of sync with their source.\n\nThe renaming should be done so you never erraneously add installation \nfiles into the repository in place of the source files\n"},{"id":"181600","messageId":"4EF2667F.9020600@gmail.com","threadId":"29197","inReplyTo":"1324147247781-7104493.post@n2.nabble.com","subject":"Re: Big Mess--How to use Git to resolve","fromName":"Neal Kreitzinger","fromEmail":"nkreitzinger@gmail.com","sentAt":"2011-12-21T23:06:39Z","receivedAt":"2011-12-21T23:06:39Z","isPatch":false,"sender":{"key":"nkreitzinger@gmail.com","avatar":null},"body":"On 12/17/2011 12:40 PM, hs_glw wrote:\n> Randal, thank you for the comprehensive answer.\n\nThe technique Randal described sounds like the 'vendor code drop' method \ndescribed in the git-rm manpage.  There you will find detailed \ninstructions on the best way to 'erase' the previous version and drop in \na tarball of the 'newer' version.\n\nHope this helps.\n\nv/r,\nneal\n"},{"id":"181601","messageId":"4EF26F7B.90206@gmail.com","threadId":"29197","inReplyTo":"1324147247781-7104493.post@n2.nabble.com","subject":"Re: Big Mess--How to use Git to resolve","fromName":"Neal Kreitzinger","fromEmail":"nkreitzinger@gmail.com","sentAt":"2011-12-21T23:44:59Z","receivedAt":"2011-12-21T23:44:59Z","isPatch":false,"sender":{"key":"nkreitzinger@gmail.com","avatar":null},"body":"On 12/17/2011 12:40 PM, hs_glw wrote:\n> Randal, thank you for the comprehensive answer.\n\nNote that Randal's solution leaves with a branch named Release that has \nthe history of the generic version of your software, and various \ncustom(er) branches that fork from the Release branch...\n\nOn 12/17/2011 6:32 AM, hs_glw wrote:\n> Some clients have customizations of the code, some have version 5 of\n> the software others have 5.2, 5.5 etc.\n>\n> My goal is to pull all the different versions in, put them all\n > together, and create a master version of the software that runs for\n > all clients.\n\nNote that you don't have to make everyone run the same version. At my \nshop we maintain dozens of concurrent divergent versions and that is the \nmain reason we chose git.  We can maintain a generic version (which most \nclients run) and also custom branches (for clients wanting to pay for \ncustomizations) forked off of the generic branch.  The custom branches \ncan periodically have the generic branch merged in to obtain the generic \nfixes/enhancements.  You can also merge the custom branches into the \ngeneric branch if you want those custom features included in a new \nrelease of the generic branch.\n\n> There will still be some files that are completely unique to each\n> client (style sheets and logos for instance).\n\nIf your logos are graphical files they are likely considered 'large \nfiles' and are likely binary files in the context of git.  It is \nrecommended you maintain these in a separate repository to keep them \nfrom bogging down your main repo (performance and storage).  You can \nmake the logo repo a submodule of the main repo (source repo).  This \nwould then make your main repo a 'super project' (contains submodules) \nin git terminology.  Alternatively, I think your source repo and logo \nrepo can just both be submodules of a super project.\n\nWe are working on implementing this so some of what I said is \ntheoretical.  Custom branches in combination with submodules seems like \nit could get pretty unwieldy if not managed properly.\n\nSome things to look into.\n\nv/r,\nneal\n"},{"id":"181603","messageId":"201112212356.pBLNuApC009997@no.baka.org","threadId":"29197","inReplyTo":"4EF26F7B.90206@gmail.com","subject":"Re: Big Mess--How to use Git to resolve","fromName":"Seth Robertson","fromEmail":"in-gitvger@baka.org","sentAt":"2011-12-21T23:56:10Z","receivedAt":"2011-12-21T23:56:10Z","isPatch":false,"sender":{"key":"in-gitvger@baka.org","avatar":null},"body":"\nIn message <4EF26F7B.90206@gmail.com>, Neal Kreitzinger writes:\n\n    We are working on implementing this so some of what I said is \n    theoretical.  Custom branches in combination with submodules seems like \n    it could get pretty unwieldy if not managed properly.\n\nYou might want to consider using gitslave (http://gitslave.sf.net)\nwhich is easier to use when you are developing both the superproject\nand the subprojects at the same time.  You don't have to use the\n\"mother-may-I\" commit protocol.\n\nThe trick with gitslave is that normally you run all git commands on\nall repositories at the same time.  So all repositories which are part\nof the superproject will be on the same branch.  This sounds like it\nis ideal for you.\n\nHowever, you do lose the strong binding between the superproject\ncommit and the subproject commit, so you would want to tag all\nprojects (trivial when using gitslave) when you go through a release\nso that you can later go back and check out synchronized repositories\nfor a particular release.\n\n\t\t\t\t\t-Seth Robertson\n"}]}