On Mon, Feb 24, 2014 at 6:34 PM, David Nadlinger <code@klickverbot.at> wrote:

On Mon, Feb 24, 2014 at 8:03 AM, Andrew Edwards <edwards.ac@gmail.com> wrote:
> On 2/24/14, 1:54 AM, Daniel Murphy wrote:
>>
>> I don't think merging back into master is feasible at this point. We have
>> been merging fixes to master first, then cherry-picking/rebasing them to the
>> release branch, and I don't think a merge to master is necessary or
>> desirable with this model.
>>
> Make sense to me.

Please don't just skip over the entire earlier discussion like this.

@Daniel: I'd argue that it is only really necessary and desirable
precisely in that model, because the Git history holds all the merging
information otherwise anyway. But I really thought we were done with
this discussion some weeks ago…

If I understand correctly, your problem is that you are jumping from one release tag to the next, and the last tag will not be a parent of the new tag.

Why can't you do the merge in two steps - merge up to the common ancestor, then create a 2.065 branch and merge the upstream release branch into that?

David

_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta