Le 3 juil. 2020 à 00:32, Ivan Pozdeev via Python-Dev <python-dev@python.org> a écrit :

At https://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