Re: git workflow - merging upwards

[Patrick Sabin <patrick.just4fun@gmail.com>]

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@pobox.com> wrote:
> Patrick Sabin <patrick.just4fun@gmail.com> 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.