On Fri, Jan 17, 2014 at 11:06 PM, Martin Nowak <[email protected]> wrote: > I don't understand the last argument. What's your workflow for updating > LDC's druntime and phobos? > How does merging back release branches help here?
We have druntime and Phobos as Git submodules. What we do is more or less, in Git pseudo-code: --- cd runtime/druntime git fetch dlang git merge dlang/v2.064-beta1 # Release or beta tag, from the release branch. cd ../.. git commit -am 'Updated LDC to 2.064' # Time passes cd runtime/druntime git fetch dlang git merge dlang/v2.065-beta1 # Another tag from the next release branch. cd ../.. git commit -am 'Updated LDC to 2.065' --- Now, if the older tag (v2.064-beta1) is not in fact an ancestor of the newer one (v2.065-beta1), we'll have to resolve all the merge conflicts ourselves again, months after the actual changes were made, and even though we probably didn't even touch the code on the LDC side. The same goes for the ldc branch on our testsuite repository, which we also reference as a submodule (https://github.com/ldc-developers/dmd-testsuite). And even for merging the frontends itself, I've been using Git to good success for the last few releases, doing something like this: --- cd dmd git checkout v2.064 # Create a dummy commit with all the LDC changes to the frontend. git checkout -b ldc cp -a ../ldc/dmd2/* src/ git commit -am 'Merged in LDC changes.' # Now merge the changes, which is easier due to the added context, # compared to just using "git diff v2.064..v2.065" and applying it to LDC. git merge v2.065 git commit -m 'Merged in new frontend.' # Export the patch and apply it to the LDC repository, where it should apply cleanly. git diff HEAD^ src > ../ldc-2.064-2.065.diff --- Exploiting the additional history information in the DMD repository makes resolving merge conflicts quite a bit easier (and Git can resolve more of them by itself), but this approach is also thwarted by diverging histories due to unmerged cherry-picks. > I think this "extra bit" of effort will make this process unsuitable. > If you cherry-pick from master onto a release branch you already have to > resolve conflicts sometimes. > Now when you merge the release branch back into master the resulting merge > conflict is non-trivial. > Difficult merges are usually best resolved by the people who made the code > changes. To get everyone to submit their pull request to the right branch by default is somewhat unrealistic, also because it is sometimes not in the submitter's responsibility to decide where a change goes (think semi-critical bug fix that might go into a point release or not). So, either we would have to tell people to redo their pull requests against the appropriate branch, which will lead to a general mess, or the onus will be on the reviewers to include the changes on the right branch (i.e. manually merging them to the release branch, the pull request will auto-close once it is merged back to master). Hm, in the last case, we'd lose auto-tester integration, so I guess that's not an option… David _______________________________________________ dmd-beta mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/dmd-beta
