Updated URL in references to Cantera's license. #709
Conversation
Codecov Report
@@ Coverage Diff @@
## master #709 +/- ##
==========================================
- Coverage 70.63% 70.63% -0.01%
==========================================
Files 372 372
Lines 43567 43567
==========================================
- Hits 30773 30772 -1
- Misses 12794 12795 +1
Continue to review full report at Codecov.
|
|
While this PR does address a known issue, it will create quite a few merge conflicts for pending pull requests (plus complete re-builds for existing toolchains when switching between branches that are not rebased). If adopted, I'd request to make this change at the last moment prior to the official release of 2.5. |
|
@ischoegl I hope this doesn't create many merge conflicts. We don't have many open PRs that touch the top of these files, I think yours are the only ones, so it should be pretty easy to sort out. For the other concern, I'm afraid there's not much we can do about that... Any long-running branches will have to rebased onto master before they're merged anyways, so they might as well be rebased after (if) this change is merged so that the rebuild only happens once. I don't see why waiting until just before 2.5 would help that much, could you clarify that? |
|
@bryanwweber I haven't checked other PR's, but there are indeed quite a few files that are affected in what is currently pending for myself. It's not a big issue, so I"ll deal with it. Regarding my comment: a version jump appears to be the obvious time when house-keeping operations are applied. |
|
@paulblum ... thank you submitting the PR regardless of my above comment(s). Depending on the order of approval of pending PR's, we'll just have to resolve the unavoidable merge conflicts case-by-case. Overall, it's a good thing if this is taken care of once and for all. |
|
@ischoegl Just having changes in the same file won't generate merge conflicts -- they need to be changes to the same line or the two adjacent lines in order for git's automatic merge algorithm to fail and require human intervention. If the two branches make the exact same changes, the merge/rebase will also succeed. Of your 6 open PRs, the only place where I get a merge conflict when rebasing is for one file (base.pyx) in #696, since you have additions immediately below the URL being updated here. I understand this isn't completely painless, but I had suggested making this change en masse to avoid having to keep asking PR authors to make the piecemeal version of this change and to keep this unrelated change out of the diff of future commits / PRs. |
|
@speth ... thanks for the clarification. I apparently did not recognize that identical changes in independent branches won't cause problems, despite this being the logical behavior. I apologize if dread of having to perform rebase-acrobatics got the better of me. |
|
@ischoegl Rebase-acrobatics-dread is certainly understandable. I'm reminded of this XKCD comic: https://xkcd.com/1597/ As @speth said, this touches areas of the files unlikely to be touched in other branches. I also wasn't aware that git would just figure things out if the same change was made twice, but I'm glad to know that's the case! Also, full disclosure, @paulblum is one of my students and I asked him to make this PR 😸 |
|
@bryanwweber ... thanks for the XKCD link - he always seems to have an appropriate comic! Glad to have learned something useful also: no more automatic alarm bells if the same lines are touched in separate branches ... (still: beware of adjacent modifications!) @paulblum In hindsight my comments were based on a false alarm on my part. Sorry about that ... |
|
To add a little data to the theory: After having merged #689, which makes a this same update to several files, Github still says "Rebase and merge can be performed automatically." So with that, I think this is safe to merge. |
Changes proposed in this pull request: