{"thread":{"id":"13783","subject":"Maintaining two branches.","startedAt":"2008-06-03T16:34:31Z","lastAt":"2008-06-03T19:09:32Z","messageCount":7,"participants":["David Brown","Stephan Beyer","Pieter de Bie","Dirk Süsserott","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"78520","messageId":"20080603163431.GA1244@old.davidb.org","threadId":"13783","inReplyTo":null,"subject":"Maintaining two branches.","fromName":"David Brown","fromEmail":"git@davidb.org","sentAt":"2008-06-03T16:34:31Z","receivedAt":"2008-06-03T16:34:31Z","isPatch":false,"sender":{"key":"git@davidb.org","avatar":"https://gravatar.com/avatar/94c86a2938470a74c2eac5e2b69afc0871f79a660295c02219597aba8cb101c1?d=mp&s=160"},"body":"Looking for some advice/ideas on a git workflow:\n\nWe have three branches of the code:\n\n   - upstream - The upstream release versions, tracks outside git repo.\n   - external - Other external patches not included in the main git repo.\n   - local - Our local development.\n\nFor release reasons, we need to keep our local branch separate, but normal\ndevelopment needs to be done on a merge of 'external' and 'local' (the tree\nneeds the merge of both just to build).  Developers will generate patches,\nand maintainers will apply these patches to 'local'.\n\nI've tried creating a 'next' branch where I merge each change from local\nand/or external, and this seems to work, but the history gets very\ncluttered with merge commits.  For some reason, history simplification\ndoesn't seem to eliminate any of these merges.\n\nWe also have an automated build/test system that checks out versions of\n'next', and when the build and test moves 'master' forward to that version.\nBecause of this, it would be nice to keep 'next' fairly up-to-date, which\nimplies having a lot of merges.\n\nDoes anyone have any better ideas on how to maintain this process?  The\n'next' and 'master' branches won't be exported too far, so could be\nreplaced with simpler history occasionally, but there is a good number of\ndevelopers who will be using them, so it would be best to not do this too\noften.\n\nThanks,\nDavid Brown\n"},{"id":"78525","messageId":"20080603180213.GA5541@leksak.fem-net","threadId":"13783","inReplyTo":"20080603163431.GA1244@old.davidb.org","subject":"Re: Maintaining two branches.","fromName":"Stephan Beyer","fromEmail":"s-beyer@gmx.net","sentAt":"2008-06-03T18:02:13Z","receivedAt":"2008-06-03T18:02:13Z","isPatch":false,"sender":{"key":"s-beyer@gmx.net","avatar":"https://avatars.githubusercontent.com/u/143889?v=4"},"body":"Hi,\n\n> I've tried creating a 'next' branch where I merge each change from local\n> and/or external, and this seems to work, but the history gets very\n> cluttered with merge commits.\n\nYou could cherry-pick commits from local and/or external instead of\nmerging. See git-cherry-pick(1).\n\nRegards,\n  Stephan\n\n-- \nStephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F\n"},{"id":"78526","messageId":"08056802-BBBC-4F1D-A1A6-2F8C381CDA2B@ai.rug.nl","threadId":"13783","inReplyTo":"20080603163431.GA1244@old.davidb.org","subject":"Re: Maintaining two branches.","fromName":"Pieter de Bie","fromEmail":"pdebie@ai.rug.nl","sentAt":"2008-06-03T18:08:09Z","receivedAt":"2008-06-03T18:08:09Z","isPatch":false,"sender":{"key":"pdebie@ai.rug.nl","avatar":null},"body":"\nOn 3 jun 2008, at 18:34, David Brown wrote:\n\n> We have three branches of the code:\n>\n>  - upstream - The upstream release versions, tracks outside git repo.\n>  - external - Other external patches not included in the main git  \n> repo.\n>  - local - Our local development.\n>\n> For release reasons, we need to keep our local branch separate, but  \n> normal\n> development needs to be done on a merge of 'external' and  \n> 'local' (the tree\n> needs the merge of both just to build).  Developers will generate  \n> patches,\n> and maintainers will apply these patches to 'local'.\n\nYou might do the same workflow that Git has with stable / master / next\n\nIf there is a new upstream release, merge it into external. If you  \nhave patches you want to show to the outside, apply those patches to  \nexternal. Then you can merge external into local. The trick is to  \nnever merge local into external.\n\nBy going only one way (upstream --> external --> local), you'll never  \nhave to worry about having to separate the different patches. Your  \nhistory will be displayed much nicer too.\n\n- Pieter\n"},{"id":"78527","messageId":"20080603181324.GA11735@old.davidb.org","threadId":"13783","inReplyTo":"20080603180213.GA5541@leksak.fem-net","subject":"Re: Maintaining two branches.","fromName":"David Brown","fromEmail":"git@davidb.org","sentAt":"2008-06-03T18:13:24Z","receivedAt":"2008-06-03T18:13:24Z","isPatch":false,"sender":{"key":"git@davidb.org","avatar":"https://gravatar.com/avatar/94c86a2938470a74c2eac5e2b69afc0871f79a660295c02219597aba8cb101c1?d=mp&s=160"},"body":"On Tue, Jun 03, 2008 at 08:02:13PM +0200, Stephan Beyer wrote:\n>Hi,\n>\n>> I've tried creating a 'next' branch where I merge each change from local\n>> and/or external, and this seems to work, but the history gets very\n>> cluttered with merge commits.\n>\n>You could cherry-pick commits from local and/or external instead of\n>merging. See git-cherry-pick(1).\n\nThe problem is that this makes future merges more difficult, since there\nisn't a history between the trees.  Our 'local' branch really is a merge of\nthe two.\n\nOnce I cherry pick anything, that branch has divergent history from the\nother branches, and I have to cherry pick from then on (or merge from then\non).\n\nDavid\n"},{"id":"78528","messageId":"20080603181731.GB11735@old.davidb.org","threadId":"13783","inReplyTo":"08056802-BBBC-4F1D-A1A6-2F8C381CDA2B@ai.rug.nl","subject":"Re: Maintaining two branches.","fromName":"David Brown","fromEmail":"git@davidb.org","sentAt":"2008-06-03T18:17:31Z","receivedAt":"2008-06-03T18:17:31Z","isPatch":false,"sender":{"key":"git@davidb.org","avatar":"https://gravatar.com/avatar/94c86a2938470a74c2eac5e2b69afc0871f79a660295c02219597aba8cb101c1?d=mp&s=160"},"body":"On Tue, Jun 03, 2008 at 08:08:09PM +0200, Pieter de Bie wrote:\n\n> You might do the same workflow that Git has with stable / master / next\n>\n> If there is a new upstream release, merge it into external. If you have \n> patches you want to show to the outside, apply those patches to external. \n> Then you can merge external into local. The trick is to never merge local \n> into external.\n>\n> By going only one way (upstream --> external --> local), you'll never have \n> to worry about having to separate the different patches. Your history will \n> be displayed much nicer too.\n\nI guess I didn't explain our dilema very well.  We _have_ to separate the\ndifferent patches, for legal reasons.  Perhaps 'external' isn't a good name\nfor the branch, maybe it should be 'other'.  Basically, the 'upstream'\nbranch is the real upstream tree.  The 'external' or 'other' branch\ncontains patches from outside our company.  We are forbidden from\nredistributing these changes, and will be having our customers get them\nfrom the same source that we do.  Then our 'local' branch is where we do\nour development.\n\nBut, we can only build the system when the 'external/other' branch is\ncombined with 'local'.  It's just that the history has to be easily\nseparable so that we can generate the patches that are on the 'local'\nbranch along with the descriptions of the external branch so the customers\ncan get the same changes.\n\nThanks,\nDavid\n"},{"id":"78530","messageId":"48459069.7090404@dirk.my1.cc","threadId":"13783","inReplyTo":"20080603181731.GB11735@old.davidb.org","subject":"Re: Maintaining two branches.","fromName":"Dirk Süsserott","fromEmail":"newsletter@dirk.my1.cc","sentAt":"2008-06-03T18:41:45Z","receivedAt":"2008-06-03T18:41:45Z","isPatch":false,"sender":{"key":"newsletter@dirk.my1.cc","avatar":null},"body":"David Brown schrieb:\n> On Tue, Jun 03, 2008 at 08:08:09PM +0200, Pieter de Bie wrote:\n>\n>> You might do the same workflow that Git has with stable / master / next\n>>\n>> If there is a new upstream release, merge it into external. If you \n>> have patches you want to show to the outside, apply those patches to \n>> external. Then you can merge external into local. The trick is to \n>> never merge local into external.\n>>\n>> By going only one way (upstream --> external --> local), you'll never \n>> have to worry about having to separate the different patches. Your \n>> history will be displayed much nicer too.\n>\n> I guess I didn't explain our dilema very well.  We _have_ to separate the\n> different patches, for legal reasons.  Perhaps 'external' isn't a good \n> name\n> for the branch, maybe it should be 'other'.  Basically, the 'upstream'\n> branch is the real upstream tree.  The 'external' or 'other' branch\n> contains patches from outside our company.  We are forbidden from\n> redistributing these changes, and will be having our customers get them\n> from the same source that we do.  Then our 'local' branch is where we do\n> our development.\nFor my understanding: does your 'other' branch contain only a 3rd party\nlibrary that you (or the 3rd party people) did patch for your purpose\nand you're not allowed to distribute that patched 3rd party lib? What\nabout using a git submodule for the 3rd party thing. The submodule\ncontains the patched library (for your development) and the customer\nis then told to supply the genuine library (from the internet) and then\napply your patches to it. Would that help you? Probably I missed\nsome legal issues here...\n\n     -- Dirk\n"},{"id":"78531","messageId":"7vod6i2v4j.fsf@gitster.siamese.dyndns.org","threadId":"13783","inReplyTo":"20080603163431.GA1244@old.davidb.org","subject":"Re: Maintaining two branches.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-03T19:09:32Z","receivedAt":"2008-06-03T19:09:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Brown <git@davidb.org> writes:\n\n> Looking for some advice/ideas on a git workflow:\n>\n> We have three branches of the code:\n>\n>   - upstream - The upstream release versions, tracks outside git repo.\n>   - external - Other external patches not included in the main git repo.\n>   - local - Our local development.\n>\n> For release reasons, we need to keep our local branch separate, but normal\n> development needs to be done on a merge of 'external' and 'local' (the tree\n> needs the merge of both just to build).  Developers will generate patches,\n> and maintainers will apply these patches to 'local'.\n>\n> I've tried creating a 'next' branch where I merge each change from local\n> and/or external, and this seems to work, but the history gets very\n> cluttered with merge commits.  For some reason, history simplification\n> doesn't seem to eliminate any of these merges.\n>\n> We also have an automated build/test system that checks out versions of\n> 'next', and when the build and test moves 'master' forward to that version.\n> Because of this, it would be nice to keep 'next' fairly up-to-date, which\n> implies having a lot of merges.\n\nYou do not have to, and very likely do not want to, merge 'next' directly\ninto 'master'.\n\nInstead of having a single local integration branch 'local', it is wiser\nto keep separate topic branches to house your local development.  Each of\nthem will start its life in an imperfect shape, and will need multiple\nrounds of fixups, which is normal, and you will merge them regularly into\n'next' to make sure everything will work together, and 'next' will have\ntons of merges for this exact reason.\n\nHowever, what you will merge to 'master' is not 'next' as a whole.\nInstead, you will merge each individual topic, only it is fully cooked and\nproved to be Ok while it has been in 'next', to 'master'.  That way, if a\nwork to enhance an appliation area took four attempts to get it right over\nfour 'next' cycles, 'next' branch may have four merges from that topic\nbranch, you will see only one merge from that topic to 'master', that\nmerges the enhancement in completed state.  At that point, 'next' will\nhave other topics in an earlier stage of polishing, and these imperfect\nones will not in 'master' yet.\n\nIOW, just like you keep separate things separate by having distinction\nbetween 'external' and 'local', by keeping separate development tracks\namong what you currently use single basket 'local' to hold, your history\nwill become much more meaningful and understandable.\n"}]}