On Fri, Jul 3, 2020 at 11:03 PM Ivan Pozdeev via Python-Dev firstname.lastname@example.org wrote:
On 03.07.2020 15:26, Henk-Jaap Wagenaar wrote:
On Fri, 3 Jul 2020 at 13:10, Ivan Pozdeev email@example.com wrote:
They'll have to synchronise their history to ours to be able to make a PR. And if they don't, it doesn't matter for us what they do with the data anyway since they are responsible for maintaining it and keeping it relevant if they need to, not us
That is not a very collaborative mindset.
I fail to see how. We provide all the tools to collaborate. If a person has a divergent history, they will see that when trying to collaborate (submit a PR or otherwise interact with our repo from theirs in any way) and will be able to fix that problem then and there.
Can somebody give an example of when we force-pushed before? Surely there should be a PEP outlining when we force push and how we communicate this to our "consumers" before/when we do so?
Even if someone isn't aware of the change, the PEPs repo *already* rewrites commits as they get merged, so any discrepancies would be papered over cleanly. Consider:
https://github.com/python/peps/pull/1488 Two commits in the pull request
https://github.com/python/peps/commit/045450aaf47941f3ee7daaa1774947b31885b2... One commit in the final repo.
If someone has the old version of the repo and creates a pull request, we'll just squash all the differences down and create a single commit that does the intent in a cleaner way. The only real effect will be a bit of noise during the PR process itself.
There has ALREADY been far more hassle resulting from this commit message than there would be from a force-push.