{"thread":{"id":"31264","subject":"git workflow - merging upwards","startedAt":"2012-08-16T19:49:02Z","lastAt":"2012-08-17T08:14:48Z","messageCount":3,"participants":["Patrick Sabin","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"197114","messageId":"502D4EAE.9010704@gmail.com","threadId":"31264","inReplyTo":null,"subject":"git workflow - merging upwards","fromName":"Patrick Sabin","fromEmail":"patrick.just4fun@gmail.com","sentAt":"2012-08-16T19:49:02Z","receivedAt":"2012-08-16T19:49:02Z","isPatch":false,"sender":{"key":"patrick.just4fun@gmail.com","avatar":null},"body":"I read through gitworkflows and want to use the Merge Upwards rule in my \nprojects:\n\n\"Always commit your fixes to the oldest supported branch that require \nthem. Then (periodically) merge the integration branches upwards into \neach other.\"\n\nThis looks great but I have some trouble in the case if I want to have\na change in an older branch and don't want to propagate the change to\nthe newer branches. Let's say I have a v1.1 and a v1.2 and now a have\na bug fix/workaround which only affects version v1.1 but not v1.2. If\nI commit to v1.1 then the periodical merge would merge the change to \nv1.2 which is what I don't want.\n\nAny ideas/workarounds for that problem?\n\n--\nPatrick\n"},{"id":"197119","messageId":"7vboia1sb8.fsf@alter.siamese.dyndns.org","threadId":"31264","inReplyTo":"502D4EAE.9010704@gmail.com","subject":"Re: git workflow - merging upwards","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-08-16T20:43:23Z","receivedAt":"2012-08-16T20:43:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Patrick Sabin <patrick.just4fun@gmail.com> writes:\n\n> I read through gitworkflows and want to use the Merge Upwards rule in\n> my projects:\n>\n> \"Always commit your fixes to the oldest supported branch that require\n> them. Then (periodically) merge the integration branches upwards into\n> each other.\"\n>\n> This looks great but I have some trouble in the case if I want to have\n> a change in an older branch and don't want to propagate the change to\n> the newer branches. Let's say I have a v1.1 and a v1.2 and now a have\n> a bug fix/workaround which only affects version v1.1 but not v1.2. If\n> I commit to v1.1 then the periodical merge would merge the change to\n> v1.2 which is what I don't want.\n>\n> Any ideas/workarounds for that problem?\n\nThe document may describe the \"upwards\" in a bit too simplified way\nfor readability.  If you have two fixes to 1.1, one applicable only\nto 1.1 and the other applicable to both, you would fork them from\ntip of maint-1.1, like so:\n\n    git checkout -b fix-1.1-only maint-1.1; do your work and commit\n    git checkout -b fix-1.1-onwards maint-1.1; do your work and commit\n\nand when they are proven to be good, you would merge both of them to\nmaint-1.1 branch:\n\n    git checkout maint-1.1\n    git merge fix-1.1-only\n    git merge fix-1.1-onwards\n\nBut merging the resulting maint-1.1 into maint-1.2 will pull the\nhistory and the change of fix-1.1-only that you do not want to have\nin maint-1.2.  You want the history so that later merge will not\npull it to maint-1.2, but you do not want the change.\n\nThe first thing to think about is if fix-1.1-only is really a \"fix\nthat only should go to maint-1.1\".\n\nIf the change is only for 1.1.x release (e.g. update version number\nfrom 1.1.4 to 1.1.5), you may not even want to have such a change\ndirectly on the maint-1.1 branch in the first place.  You would\nrather want to have release-1.1 branch that is forked from maint-1.1\nbranch, that contains the whole of maint-1.1 branch, and also\ncontains the \"update version number from 1.1.x to 1.1.y\" changes\nthat are not in the maint-1.1 branch [*1*].\n\nThat arrangement may be sufficient to allow you merge maint-1.1 to\nmaint-1.2 sanely.\n\nOtherwise, you would fork another branch after merging fix-1.1-*\nbranches to maint-1.1 to merge it upwards.  After these two merges\nillustrated above, while still on maint-1.1, you would do:\n\n    git checkout -B merge-1.1-to-1.2 maint-1.1\n    git revert -m 1 maint-1.1~1 ;# revert the fix-1.1-only merge\n\nwhich would result in a state as if you merged fix-1.1-onwards but\nnot fix-1.1-only to the original maint-1.1 branch.  But the history\nof this branch contains both fix-1.1-only and fix-1.1-onwards.\n\nAnd merge that result to maint-1.2, i.e.\n\n    git checkout maint-1.2\n    git merge merge-1.1-to-1.2\n    git branch -d merge-1.1-to-1.2\n\nThat way, future merges from maint-1.1 to maint-1.2 will not drag\nthe change of fix-1.1-only.\n\n\n[Footnote]\n\n*1* This principle applies not just to \"release numbers\". If you\nwant both maint-1.1 and maint-1.2 as generic two codebases, tweaks\nmeant only for customers of maint-1.1 track should *not* go to\nmaint-1.1, but customer-1.1 branch that forks from maint-1.1. That\nway, you can keep the generic branches clean from \"this is only for\nthat branch\" kind of changes.\n"},{"id":"197172","messageId":"CAGATVH7kjm--CEDjNrLuaTgqrm6P7yD1X_iCMN_NwY_QNqqHzQ@mail.gmail.com","threadId":"31264","inReplyTo":"7vboia1sb8.fsf@alter.siamese.dyndns.org","subject":"Re: git workflow - merging upwards","fromName":"Patrick Sabin","fromEmail":"patrick.just4fun@gmail.com","sentAt":"2012-08-17T08:14:48Z","receivedAt":"2012-08-17T08:14:48Z","isPatch":false,"sender":{"key":"patrick.just4fun@gmail.com","avatar":null},"body":"Thanks, for the great answer.\n\nWhat I am still concerned about is that in my project I plan to make bigger\nstructural changes (let's say in 1.2) while still developing in the\nolder branch\n(let's say 1.1 with the old structure. I expect that there will be many changes\nwhich I think that they can't be easily merged from 1.1 to 1.2.\n\nDo you think it is better to have a heavily used 1.1.1 branch which\ncontains all\nthe changes for 1.1.* only, use many revert commits, or should I avoid merging\nfrom 1.1 to 1.2 and go for cherry-picking instead?\n\nOn Thu, Aug 16, 2012 at 10:43 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Patrick Sabin <patrick.just4fun@gmail.com> writes:\n>\n>> I read through gitworkflows and want to use the Merge Upwards rule in\n>> my projects:\n>>\n>> \"Always commit your fixes to the oldest supported branch that require\n>> them. Then (periodically) merge the integration branches upwards into\n>> each other.\"\n>>\n>> This looks great but I have some trouble in the case if I want to have\n>> a change in an older branch and don't want to propagate the change to\n>> the newer branches. Let's say I have a v1.1 and a v1.2 and now a have\n>> a bug fix/workaround which only affects version v1.1 but not v1.2. If\n>> I commit to v1.1 then the periodical merge would merge the change to\n>> v1.2 which is what I don't want.\n>>\n>> Any ideas/workarounds for that problem?\n>\n> The document may describe the \"upwards\" in a bit too simplified way\n> for readability.  If you have two fixes to 1.1, one applicable only\n> to 1.1 and the other applicable to both, you would fork them from\n> tip of maint-1.1, like so:\n>\n>     git checkout -b fix-1.1-only maint-1.1; do your work and commit\n>     git checkout -b fix-1.1-onwards maint-1.1; do your work and commit\n>\n> and when they are proven to be good, you would merge both of them to\n> maint-1.1 branch:\n>\n>     git checkout maint-1.1\n>     git merge fix-1.1-only\n>     git merge fix-1.1-onwards\n>\n> But merging the resulting maint-1.1 into maint-1.2 will pull the\n> history and the change of fix-1.1-only that you do not want to have\n> in maint-1.2.  You want the history so that later merge will not\n> pull it to maint-1.2, but you do not want the change.\n>\n> The first thing to think about is if fix-1.1-only is really a \"fix\n> that only should go to maint-1.1\".\n>\n> If the change is only for 1.1.x release (e.g. update version number\n> from 1.1.4 to 1.1.5), you may not even want to have such a change\n> directly on the maint-1.1 branch in the first place.  You would\n> rather want to have release-1.1 branch that is forked from maint-1.1\n> branch, that contains the whole of maint-1.1 branch, and also\n> contains the \"update version number from 1.1.x to 1.1.y\" changes\n> that are not in the maint-1.1 branch [*1*].\n>\n> That arrangement may be sufficient to allow you merge maint-1.1 to\n> maint-1.2 sanely.\n>\n> Otherwise, you would fork another branch after merging fix-1.1-*\n> branches to maint-1.1 to merge it upwards.  After these two merges\n> illustrated above, while still on maint-1.1, you would do:\n>\n>     git checkout -B merge-1.1-to-1.2 maint-1.1\n>     git revert -m 1 maint-1.1~1 ;# revert the fix-1.1-only merge\n>\n> which would result in a state as if you merged fix-1.1-onwards but\n> not fix-1.1-only to the original maint-1.1 branch.  But the history\n> of this branch contains both fix-1.1-only and fix-1.1-onwards.\n>\n> And merge that result to maint-1.2, i.e.\n>\n>     git checkout maint-1.2\n>     git merge merge-1.1-to-1.2\n>     git branch -d merge-1.1-to-1.2\n>\n> That way, future merges from maint-1.1 to maint-1.2 will not drag\n> the change of fix-1.1-only.\n>\n>\n> [Footnote]\n>\n> *1* This principle applies not just to \"release numbers\". If you\n> want both maint-1.1 and maint-1.2 as generic two codebases, tweaks\n> meant only for customers of maint-1.1 track should *not* go to\n> maint-1.1, but customer-1.1 branch that forks from maint-1.1. That\n> way, you can keep the generic branches clean from \"this is only for\n> that branch\" kind of changes.\n"}]}