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.
