Thanks, for the great answer. What I am still concerned about is that in my project I plan to make bigger structural changes (let's say in 1.2) while still developing in the older branch (let's say 1.1 with the old structure. I expect that there will be many changes which I think that they can't be easily merged from 1.1 to 1.2. Do you think it is better to have a heavily used 1.1.1 branch which contains all the changes for 1.1.* only, use many revert commits, or should I avoid merging from 1.1 to 1.2 and go for cherry-picking instead? On Thu, Aug 16, 2012 at 10:43 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Patrick Sabin <patrick.just4fun@xxxxxxxxx> writes: > >> I read through gitworkflows and want to use the Merge Upwards rule in >> my projects: >> >> "Always commit your fixes to the oldest supported branch that require >> them. Then (periodically) merge the integration branches upwards into >> each other." >> >> This looks great but I have some trouble in the case if I want to have >> a change in an older branch and don't want to propagate the change to >> the newer branches. Let's say I have a v1.1 and a v1.2 and now a have >> a bug fix/workaround which only affects version v1.1 but not v1.2. If >> I commit to v1.1 then the periodical merge would merge the change to >> v1.2 which is what I don't want. >> >> Any ideas/workarounds for that problem? > > The document may describe the "upwards" in a bit too simplified way > for readability. If you have two fixes to 1.1, one applicable only > to 1.1 and the other applicable to both, you would fork them from > tip of maint-1.1, like so: > > git checkout -b fix-1.1-only maint-1.1; do your work and commit > git checkout -b fix-1.1-onwards maint-1.1; do your work and commit > > and when they are proven to be good, you would merge both of them to > maint-1.1 branch: > > git checkout maint-1.1 > git merge fix-1.1-only > git merge fix-1.1-onwards > > But merging the resulting maint-1.1 into maint-1.2 will pull the > history and the change of fix-1.1-only that you do not want to have > in maint-1.2. You want the history so that later merge will not > pull it to maint-1.2, but you do not want the change. > > The first thing to think about is if fix-1.1-only is really a "fix > that only should go to maint-1.1". > > If the change is only for 1.1.x release (e.g. update version number > from 1.1.4 to 1.1.5), you may not even want to have such a change > directly on the maint-1.1 branch in the first place. You would > rather want to have release-1.1 branch that is forked from maint-1.1 > branch, that contains the whole of maint-1.1 branch, and also > contains the "update version number from 1.1.x to 1.1.y" changes > that are not in the maint-1.1 branch [*1*]. > > That arrangement may be sufficient to allow you merge maint-1.1 to > maint-1.2 sanely. > > Otherwise, you would fork another branch after merging fix-1.1-* > branches to maint-1.1 to merge it upwards. After these two merges > illustrated above, while still on maint-1.1, you would do: > > git checkout -B merge-1.1-to-1.2 maint-1.1 > git revert -m 1 maint-1.1~1 ;# revert the fix-1.1-only merge > > which would result in a state as if you merged fix-1.1-onwards but > not fix-1.1-only to the original maint-1.1 branch. But the history > of this branch contains both fix-1.1-only and fix-1.1-onwards. > > And merge that result to maint-1.2, i.e. > > git checkout maint-1.2 > git merge merge-1.1-to-1.2 > git branch -d merge-1.1-to-1.2 > > That way, future merges from maint-1.1 to maint-1.2 will not drag > the change of fix-1.1-only. > > > [Footnote] > > *1* This principle applies not just to "release numbers". If you > want both maint-1.1 and maint-1.2 as generic two codebases, tweaks > meant only for customers of maint-1.1 track should *not* go to > maint-1.1, but customer-1.1 branch that forks from maint-1.1. That > way, you can keep the generic branches clean from "this is only for > that branch" kind of changes. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html