On 7/2/2020 6:49 PM, Rémi Lapeyre wrote:
Le 3 juil. 2020 à 00:32, Ivan Pozdeev via Python-Dev
<python-dev@python.org <mailto:python-dev@python.org>> a écrit :
Athttps://git-scm.com/book/en/v2/Git-Branching-Rebasing#_rebase_vs_merge,
they say that the argument of whether to allow overwriting history in
VCSes stems from two opposing views on what a project's history
should be. One is that is shall be a raw, unedited record of events
as they happened; the other is that is should be a (polished and
adapted for future reading) story of how the project was made.
That's for how to add the commit on the master branch, once it’s there
you can’t update it without breaking every fork and PR.
For all purposes, the history is immutable for example if you look at
the v3.9.0b3 tag, it is signed so you know that this is the code that
went into the release according to the person that signed the commit.
If you changed any parent commit, it would change all childs and the
signature would then be invalid which would be an issue.
But this commit was to the peps repo, which has far fewer commits, one
branch, no tags, and only 10 PRs. So while it's still an issue, it's not
as big a deal as if we were talking about the cpython repo.
I don't know how many forks have been made since the commit in question.
Eric
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/KQSHT5RZPPUBBIALMANFTXCMIBGSIR5Z/
Code of Conduct: http://python.org/psf/codeofconduct/
