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.
>
>
> On Mon, Feb 24, 2014 at 5:46 PM, Andrew Edwards <edwards.ac@gmail.com <mailto:edwards.ac@gmail.com>> wrote:
>
>
>     Merger of all branches with master were successfull with exception
>     of DMD and PHOBOS.
>
>     Following are the conflicts that will be encountered for DMD:
>         seireitei:dmd ace$ git merge 2.065
>         Auto-merging test/runnable/xtest46.d
>         CONFLICT (content): Merge conflict in test/runnable/xtest46.d
>         Auto-merging test/runnable/aliasthis.d
>         CONFLICT (content): Merge conflict in test/runnable/aliasthis.d
>         Auto-merging src/typinf.c
>         CONFLICT (content): Merge conflict in src/typinf.c
>         Auto-merging src/traits.c
>         CONFLICT (content): Merge conflict in src/traits.c
>         Auto-merging src/template.h
>         Auto-merging src/template.c
>         CONFLICT (content): Merge conflict in src/template.c
>         Auto-merging src/struct.c
>         CONFLICT (content): Merge conflict in src/struct.c
>         Auto-merging src/parse.c
>         CONFLICT (content): Merge conflict in src/parse.c
>         Auto-merging src/mtype.h
>         CONFLICT (content): Merge conflict in src/mtype.h
>         Auto-merging src/mtype.c
>         CONFLICT (content): Merge conflict in src/mtype.c
>         Auto-merging src/interpret.c
>         CONFLICT (content): Merge conflict in src/interpret.c
>         Auto-merging src/inline.c
>         CONFLICT (content): Merge conflict in src/inline.c
>         Auto-merging src/glue.c
>         CONFLICT (content): Merge conflict in src/glue.c
>         Auto-merging src/func.c
>         CONFLICT (content): Merge conflict in src/func.c
>         Auto-merging src/expression.h
>         CONFLICT (content): Merge conflict in src/expression.h
>         Auto-merging src/expression.c
>         CONFLICT (content): Merge conflict in src/expression.c
>         Auto-merging src/e2ir.c
>         CONFLICT (content): Merge conflict in src/e2ir.c
>         Auto-merging src/dsymbol.h
>         CONFLICT (content): Merge conflict in src/dsymbol.h
>         Auto-merging src/doc.c
>         CONFLICT (content): Merge conflict in src/doc.c
>         Auto-merging src/declaration.h
>         CONFLICT (content): Merge conflict in src/declaration.h
>         Auto-merging src/ctfeexpr.c
>         CONFLICT (content): Merge conflict in src/ctfeexpr.c
>         Auto-merging src/cast.c
>         Auto-merging src/attrib.c
>         CONFLICT (content): Merge conflict in src/attrib.c
>         Automatic merge failed; fix conflicts and then commit the result.
>
>     Following are the conflicts that will be encountered for PHOBOS:
>         seireitei:phobos ace$ git merge 2.065
>         Auto-merging std/traits.d
>         CONFLICT (content): Merge conflict in std/traits.d
>         Auto-merging std/algorithm.d
>         CONFLICT (content): Merge conflict in std/algorithm.d
>         Automatic merge failed; fix conflicts and then commit the result.
>
>     I have aborted these mergers so am not yet sure what the actual
>     conflicts are or how time-consuming resolution will be.
>

On 2/24/14, 2:34 AM, David Nadlinger 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…
>
David, I honestly think this is a waste of time. Since nothing is directly implemented into 2.065 (everything contained in it were either cherry-picked directly or via pull request from master) my path to resolving all of these issues ends up being the same. I review the commit history and see which changes effectively caused the divergence. In every case, master's current state is a natural progressing from where 2.065 was extracted so I end up choosing to keep what's in master as the  resolution path. This is a lot of time wasted or zero gain: time that can be better spent doing things that are important, like tracking and picking changes that address regressions to 2.065.0 in preparation for a point release and preparing the beta release for 2.066.
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 27 Feb 2014, at 19:30, Andrew Edwards wrote:
> David, I honestly think this is a waste of time. Since nothing is directly implemented into 2.065 (everything contained in it were either cherry-picked directly or via pull request from master) […]

If you are sure that there are no commits on the release branch that are not in master (there have been issues with this in the past), just create a merge commit, resolving all the differences by defaulting to the master version (cf. merge strategies) or just setting the content of the merge commit to master.

> This is a lot of time wasted [f]or zero gain

In (your) "[dmd-beta] Preparation for 2.65" thread, I explained in considerable detail why we need to do precisely the same thing when merging the release into LDC later, only that we don't have the knowledge of what exactly happened in the release phase.

If you have suggestions on how to better handle the situation, be sure to let me know though.

David

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

On 2/27/14, 5:33 PM, David Nadlinger wrote:
> On 27 Feb 2014, at 19:30, Andrew Edwards wrote:
>> David, I honestly think this is a waste of time. Since nothing is
>> directly implemented into 2.065 (everything contained in it were
>> either cherry-picked directly or via pull request from master) […]
> If you are sure that there are no commits on the release branch that are
> not in master (there have been issues with this in the past), just
> create a merge commit, resolving all the differences by defaulting to
> the master version (cf. merge strategies) or just setting the content of
> the merge commit to master.
>
>
Merger complete.
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 2/27/14, 5:33 PM, David Nadlinger wrote:

A quick look at the auto tester shows that everything is failing. I am assuming that it is directly related to the merge. Please assist in resolving this issue. For the record, this is the last time I will attempt a merger between release branches and master. If this is absolutely necessary, I suggest that you take the responsibility of conducting it once a release is published.

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

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
>