Build Master: Progress toward 2.065

[Andrew Edwards]

On 12/10/13, 10:18 AM, Dicebot wrote:
> On Tuesday, 10 December 2013 at 15:09:13 UTC, Leandro Lucarella wrote:
>> I don't understand. Rebasing the release branch on top of master
>> shouldn't be an option, as it means you are taking all the changes to
>> master and put them in the release branch. That's just using master as
>> a release branch. The other way around would be crazy.
>
> Yes, of course, it is not a normal thing to do. As far as I understand,
> Andrew wants to restart release branch from scratch, based on current
> master state (because old base happened before he started working on
> release management). In that case it is a natural (and exceptional)
> solution.

Yes. This is precisely the case and exactly what I'm trying to achieve. 
My hope is that by doing this I will not be adversely effecting any code 
already merged into the branch. If there is a chance that this might 
happen, I would rather cherry-pick the items that must be included or 
simply forgo such inclusion until the next release.

>> What problems do you see merging cherry-picked stuff back into master?
>> IIRC git should be smart enough to recognize duplicated commits and
>> ignore them, at least if you merge often.
>
> In my experience it was not smart enough. It may have changed in latest
> versions of course.