Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
BUG: Use enable_if with SFINAE to dispatch #1018
Jun 13, 2019
It looks like your
I only get some seemingly unrelated linking errors now:
Update: The linking errors does not occur when building with
I personally don't care about getting these tests passing - just wanted to let you know.
Yes, this patch is ready to go. This commit is for both the release and the master branches. I created PR #1036 for the master branch.
It's not clear to me the current best practice to get a patch/commit into the release branch. I just have two separate PR for the same commit now, targeting the two separate branches.
With respect to longer term maintainability, it looks like the best way is to merge a commit into release, then merge release branch into master. That way there should be no merge conflict on rebase, now or in the future - at least nearer future.
If a commit is merged separately into release and master branch, it gets counted twice as @N-Dekker recently noticed with 5.0.0 release notes.
Jun 24, 2019
7 of 11 checks passed
This is not accurate. If a same commit is merged into both, it only gets counted once. On the other hand if a commit is merged into master, then rebased onto release such that it is another commit is created the came changes with a new hash will be merged. However it is relatively hard to ensure that the same commit is merged with Github, this was one of the nice advantages of the Kitware stage repo/process.
The downside of merging directly into release, is that we don't get the nightly testing on the merged commit before merging in to the more stable release branch.
@thewtex do you think we should go the route of first merging to master, waiting a night or two, then merging to release? And possibly merging release into master after that, to reduce changes of merge conflicts in the future?