Release/v3.7.0

[TonVanDenBroek]

Some more modifications foe OpenEXR 3.

[c-lipka]

Not sure why you opened another set of pull requests. Your earlier pull requests have already been merged.

Squash-merged, to be precise. A squash-merge is effectively an entirely new commit, that includes all the changes from a pull request. Such squash-merges are usually done to keep the change history simple, as they replace an arbitrarily long chain of commits with a single one.

The downside is that, if the author of the pull request created their commits in the original branch (in their own copy of the repo), their copy is then out of sync with the "upstream" repo - which, as I only now realize, is what must have happened in your case, and which might have thrown you off and make you think something didn't quite work with your pull requests.

---

To avoid this problem in the future, it is good practice to use separate dedicated branches to prepare pull requests; those can be deleted later once the pull request has been merged and the branch is no longer needed. For example, to prepare a pull request to fix some hypothetical GitHub issue 42 in POV-Ray v3.8.0, you might create a new branch bugfix_42_v380 from release/v3.8.0, commit your changes to bugfix_42_v380, and then submit a pull request for your branch bugfix_42_v380 vs. the official branch release/v3.8.0.

This also has the advantage that you could (if you were so inclined) already start working on some other unrelated issue without messing up the pull request for issue 4711.

This is in part on me, as I could have spotted the issue when reviewing your pull request. I'll try to pay more attention to such details in the future.

---

To rectify the situation now that it has already happened, and get the two branches back in a clean state, my recommendation would be to create a new(!) local clone of the POV-Ray/povray repository, make sure it is up to date, and then force-push the problematic branches to your own GitHub repo, using the following commands:

git remote add my_repo
git push --force my_repo release/v3.7.0
git push --force my_repo release/v3.8.0

This should, in theory, discard the current history of release/v3.7.0 and release/v3.8.0 in your fork on GitHub, and overwrite it with the history from the local repo (which should match the official repo, by virtue of being a clone thereof).

If for some reason you want to keep your history of the individual changes you made, you can first create a new branch from your version of release/v3.7.0. Or you could rename the release/v3.7.0 branch in your GitHub to something else before doing that magic git push, in which case you should be able to get away without the --force parameter.

Once you're done with that procedure, you can delete the local clone again.

[TonVanDenBroek]

Sorry about that. I blame that on my lack of knowledge of Git. I had to do a new commit to process the changes, so, therefore, a new pull request. I'll try to remember this for the next time, when I might be able to help a bit with povray. Cheers Ton,

…

On Sat, 10 Jul 2021 at 18:47, Christoph Lipka ***@***.***> wrote: Closed #424 <#424>. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#424 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AUUKRRXXSZYFOHVXYZUWFG3TW7UIJANCNFSM5ADT6H3Q> .