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.
While I'm firmly in camp story (long story short, it makes history much more useful for everything except playing the blame game), in this case, there's a case-specific reason, too.
The remarks that stem the controversy have nothing to do with commit's intent in technical terms: clarifying wording that cause misunderstanding. They were simply speculations by the author (and misguided ones at that since Strunk & White are actually names).
Leaving this commit as it is will leave no trace of any "comment on the commit" and later discussion to a future onlooker. And as a commit is the official codebase, it will still appear as endorsed by the dev team. There'd be no clue that this is not the "final" thoughts on the matter and there something else, somewhere else, and who knows where.
While editing the message to just state facts (clarifying the wording) and omit specuilations, it will still serve its purpose -- while stating the actual, valid, endorsed by the team (since the concensus is that the change itself was useful and should not be reverted but could be improved further, as a separate initiative), clean from speculations intent of the edit.
On 02.07.2020 23:17, David Antonini wrote:
No contention to the contrary, but as a routine, post-merge git history rewrite, not a grand plan, from what I understand.
Oh the other hand, an 'official' comment on the commit, recognising the issue with the original commit message, the following discussion, and any conclusions that get reached, might be better, in my opinion. I prefer to recognise and critique, rather than erase, 'historical' history, as a rule (as opposed to git history). I think similar damage is done in this case, when the record, and opportunity to point to and learn from it, is erased.
Date: Thu, 2 Jul 2020 21:33:56 +0300 From: Ivan Pozdeev email@example.com Subject: [Python-Dev] Re: Recent PEP-8 change (Antoine Pitrou) To: firstname.lastname@example.org Message-ID: email@example.com Content-Type: text/plain; charset=utf-8; format=flowed On 02.07.2020 21:20, Chris Angelico wrote:
On Fri, Jul 3, 2020 at 4:09 AM David Mertz firstname.lastname@example.org wrote:
An issue is that commit messages are uneditable after merge, so something written somewhere suggesting consideration of this would be
a good idea, with authors/mergers bearing this in mind, however unusual a change on this basis would be. This would be additional burden on the core dev team, but if commitment is to be made to inclusivity, it might be what's necessary.
I don't think so. https://docs.github.com/en/github/committing-changes-to-your-project/changin.... Interactive rebasing
is perfectly possible, isn't it. I admit my git-fu isn't that strong, but I've done something that I *think* is the same as this. It's possible I'm missing some distinction between the trees I've modified and the current one, but I don't think so.
When you do that sort of rewriting, you're constructing a new and independent history and then saying "hey, this is the history I want everyone to respect now, thanks". It's full-on Back To The Future stuff, and can have annoying or serious consequences with everyone who has a clone or fork of the repo.
It would be extremely annoying to anyone who has an open PR at the time of the rewrite, but the annoyance would be temporary (hopefully one-off).
If you are talking about rewriting the PEP8 commit, it has proven to cause so much damage that this is warranted despite the inconveniences IMO.
ChrisA _______________________________________________ Python-Dev mailing list -- email@example.com To unsubscribe send an email to firstname.lastname@example.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://email@example.com/message/A2XBFOH5... Code of Conduct: http://python.org/psf/codeofconduct/ http://python.org/psf/codeofconduct/ -- Regards, Ivan
Python-Dev mailing list -- firstname.lastname@example.org To unsubscribe send an email to email@example.com https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://firstname.lastname@example.org/message/ZZKGBARO... Code of Conduct: http://python.org/psf/codeofconduct/ -- Regards, Ivan