On Fri, Jul 3, 2020 at 11:03 PM Ivan Pozdeev via Python-Dev
<python-dev@python.org> wrote:
>
>
> On 03.07.2020 15:26, Henk-Jaap Wagenaar wrote:
>
> On Fri, 3 Jul 2020 at 13:10, Ivan Pozdeev <vano@mail.mipt.ru> wrote:
>>
>> So what?
>
> Unnecessary
>>
>> 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,
That is not the right way of putting it in my opinion. What you describe below is rewriting commits when merging/completing a pull request (squashing is common). That is very different to going back to a commit that is already in the same branch and rewriting that.
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/045450aaf47941f3ee7daaa1774947b31885b2aa
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.
Maybe, but rewriting it would (a) not make the "hassle" go away and (b) would in my view create more "hassle".
ChrisA
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/W3UOLWJZHRLJA75PJZ5O434FPPLBZMLQ/
Code of Conduct: http://python.org/psf/codeofconduct/