{"thread":{"id":"35827","subject":"git best strategy for two version development","startedAt":"2014-02-08T02:06:41Z","lastAt":"2014-02-08T12:09:15Z","messageCount":4,"participants":["Carlos Pereira","brian m. carlson","Øystein Walle"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"234487","messageId":"52F59131.5000808@ist.utl.pt","threadId":"35827","inReplyTo":null,"subject":"git best strategy for two version development","fromName":"Carlos Pereira","fromEmail":"jose.carlos.pereira@ist.utl.pt","sentAt":"2014-02-08T02:06:41Z","receivedAt":"2014-02-08T02:06:41Z","isPatch":false,"sender":{"key":"jose.carlos.pereira@ist.utl.pt","avatar":null},"body":"Hello,\n\nI am a git and CVS newbie, I bought and red most of the excellent Pro \nGit book by Scott Chacon, but I still have a doubt. I have a package \nthat I distribute in two versions differing only in one library: \nversion_A uses this library, version_B uses my own code to replace it. \nFor strategic reasons I want to keep it this way for the time being. \nBoth versions have the same documentation, the same data files, and 99% \nof the source code is the same (a few makefile changes, two additional \nfiles in version_B and some minor changes: a diff -r has only 170 \nlines). The question is what is the best strategy to manage a situation \nlike this with git?\n\nShall I maintain two different repositories? I don't think so...\n\nApparently the best solution would be to maintain two long term \nbranches, say mater_A and master_B, and merge all later developments in \nboth branches, keeping the initial difference... Specifically:\n\n1) do some new work in branch master_A, commit, etc.\n2) checkout master_B and merge the new work in master_B, without merging \nthe initial diff between the two versions.\n\nWhat is the better way to do that?\n\nI suppose this is a fairly common situation, for example, some \nstandalone code distributed with two different GUI toolkits. I could \ncarefully choose which commits should be merged in both branches (the \nchanges in standalone code) and which should not (the changes in GUI \ncode), but that is error-prone and seems to miss the whole point of \nusing a managment system...\n\nHow shall I handle this? Thanks for your help!\n\nRegards,\nCarlos Pereira,\nhttp://www.gamgi.org/\n"},{"id":"234488","messageId":"20140208035610.GK635004@vauxhall.crustytoothpaste.net","threadId":"35827","inReplyTo":"52F59131.5000808@ist.utl.pt","subject":"Re: git best strategy for two version development","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2014-02-08T03:56:11Z","receivedAt":"2014-02-08T03:56:11Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Sat, Feb 08, 2014 at 02:06:41AM +0000, Carlos Pereira wrote:\n> Hello,\n> \n> I am a git and CVS newbie, I bought and red most of the excellent\n> Pro Git book by Scott Chacon, but I still have a doubt. I have a\n> package that I distribute in two versions differing only in one\n> library: version_A uses this library, version_B uses my own code to\n> replace it. For strategic reasons I want to keep it this way for the\n> time being. Both versions have the same documentation, the same data\n> files, and 99% of the source code is the same (a few makefile\n> changes, two additional files in version_B and some minor changes: a\n> diff -r has only 170 lines). The question is what is the best\n> strategy to manage a situation like this with git?\n> \n> Shall I maintain two different repositories? I don't think so...\n> \n> Apparently the best solution would be to maintain two long term\n> branches, say mater_A and master_B, and merge all later developments\n> in both branches, keeping the initial difference... Specifically:\n> \n> 1) do some new work in branch master_A, commit, etc.\n> 2) checkout master_B and merge the new work in master_B, without\n> merging the initial diff between the two versions.\n> \n> What is the better way to do that?\n\nThat's pretty much the way to do it.  If you check in master-A, then\ncreate the master-B branch off of that, copying in the code from B and\nchecking it in, then when you merge from master-A to master-B, git will\nbasically do the right thing.  Changes you make on master-A that are\nspecific to that version will probably conflict, but they should be easy\nto fix up.\n\nI basically do this for a consulting project for a client: there's\ngeneric code in master, and a special branch for the client.  Since most\nchanges don't touch the modified code, conflicts are infrequent, and I\ncan fix them up when they occur.  I also do it for my dotfiles, which\nvary slightly between home and work.\n\nYou could also make the changes to master-B as a set of commits on top\nof master-A, and always rebase master-B on master-A, but this isn't a\ngood solution if other people are going to be using your code.  It has\nthe benefits of keeping the history free of frequent merges, which may\nor may not be important to you; it doesn't really bother me very much.\n\n-- \nbrian m. carlson / brian with sandals: Houston, Texas, US\n+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only\nOpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187\n"},{"id":"234498","messageId":"52F5F10A.2080708@ist.utl.pt","threadId":"35827","inReplyTo":"20140208035610.GK635004@vauxhall.crustytoothpaste.net","subject":"Re: git best strategy for two version development","fromName":"Carlos Pereira","fromEmail":"jose.carlos.pereira@ist.utl.pt","sentAt":"2014-02-08T08:55:38Z","receivedAt":"2014-02-08T08:55:38Z","isPatch":false,"sender":{"key":"jose.carlos.pereira@ist.utl.pt","avatar":null},"body":"On 02/08/2014 03:56 AM, brian m. carlson wrote:\n> On Sat, Feb 08, 2014 at 02:06:41AM +0000, Carlos Pereira wrote:\n>    \n>> Hello,\n>>\n>> I am a git and CVS newbie, I bought and red most of the excellent\n>> Pro Git book by Scott Chacon, but I still have a doubt. I have a\n>> package that I distribute in two versions differing only in one\n>> library: version_A uses this library, version_B uses my own code to\n>> replace it. For strategic reasons I want to keep it this way for the\n>> time being. Both versions have the same documentation, the same data\n>> files, and 99% of the source code is the same (a few makefile\n>> changes, two additional files in version_B and some minor changes: a\n>> diff -r has only 170 lines). The question is what is the best\n>> strategy to manage a situation like this with git?\n>>\n>> Shall I maintain two different repositories? I don't think so...\n>>\n>> Apparently the best solution would be to maintain two long term\n>> branches, say mater_A and master_B, and merge all later developments\n>> in both branches, keeping the initial difference... Specifically:\n>>\n>> 1) do some new work in branch master_A, commit, etc.\n>> 2) checkout master_B and merge the new work in master_B, without\n>> merging the initial diff between the two versions.\n>>\n>> What is the better way to do that?\n>>      \n> That's pretty much the way to do it.  If you check in master-A, then\n> create the master-B branch off of that, copying in the code from B and\n> checking it in, then when you merge from master-A to master-B, git will\n> basically do the right thing.  Changes you make on master-A that are\n> specific to that version will probably conflict, but they should be easy\n> to fix up.\n>    \nYou are right! git does not try to merge everything, only changes \ncommited on the other branch (branch-A), after creating branch-B... \notherwise it would be reverting the work done on the current branch, \nwhich does not make much sense...\n\nThank you very much...\nC\n> I basically do this for a consulting project for a client: there's\n> generic code in master, and a special branch for the client.  Since most\n> changes don't touch the modified code, conflicts are infrequent, and I\n> can fix them up when they occur.  I also do it for my dotfiles, which\n> vary slightly between home and work.\n>\n> You could also make the changes to master-B as a set of commits on top\n> of master-A, and always rebase master-B on master-A, but this isn't a\n> good solution if other people are going to be using your code.  It has\n> the benefits of keeping the history free of frequent merges, which may\n> or may not be important to you; it doesn't really bother me very much.\n>\n>    \n"},{"id":"234503","messageId":"loom.20140208T130440-803@post.gmane.org","threadId":"35827","inReplyTo":"52F59131.5000808@ist.utl.pt","subject":"Re: git best strategy for two version development","fromName":"Øystein Walle","fromEmail":"oystwa@gmail.com","sentAt":"2014-02-08T12:09:15Z","receivedAt":"2014-02-08T12:09:15Z","isPatch":false,"sender":{"key":"oystwa@gmail.com","avatar":"https://avatars.githubusercontent.com/u/794585?v=4"},"body":"Carlos Pereira <jose.carlos.pereira <at> ist.utl.pt> writes:\n\n> \n> Hello,\n> \n> I am a git and CVS newbie, I bought and red most of the excellent Pro \n> Git book by Scott Chacon, but I still have a doubt. I have a package \n> that I distribute in two versions differing only in one library: \n> version_A uses this library, version_B uses my own code to replace it. \n> For strategic reasons I want to keep it this way for the time being. \n> Both versions have the same documentation, the same data files, and 99% \n> of the source code is the same (a few makefile changes, two additional \n> files in version_B and some minor changes: a diff -r has only 170 \n> lines). The question is what is the best strategy to manage a situation \n> like this with git?\n> \n> Shall I maintain two different repositories? I don't think so...\n> \n\nIf the changes are as small as you say, is it an option to use just one\nbranch but have two possible build configurations? That seems like the\neasiest way to do it, in my opinion. E.g.:\n\n    $ make LIB=versionA\n    $ make LIB=versionB\n\nConsider the above as pseudo-code, though. I don't know what build\nsystem you use or even if your package is even something that is\n\"built\". But you get the idea.\n\nØsse\n"}]}