[Python-Dev] Re: Re Re: Recent PEP-8 change (Ivan Pozdeev)

2020-07-03 Thread Paul Moore
On Thu, 2 Jul 2020 at 21:18, 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.

David,
When you post, you (or more likely your mail program) somehow adds the
name of the author of the post that you are replying to in parentheses
after the subject. This breaks threading (at least in the GMail web
interface) and is fairly disruptive to following the conversation.
Could you try to stop this happening, please, in the interests of
keeping things more readable?

Thanks,
Paul
___
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/X3PXNFFICK7YF2KKLB65CBH24PGLZ74U/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Re Re: Recent PEP-8 change (Ivan Pozdeev)

2020-07-02 Thread Jonathan Goble
On Thu, Jul 2, 2020 at 7:55 PM Eric V. Smith  wrote:

> 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.
>
I don't know about new forks that are just sitting there, but GitHub has a
handy network graph that shows where every fork has diverged from the main
repo: https://github.com/python/peps/network

If you look to the right of the line down to KeanaBerlin on June 26, it
seems that six people have pushed commits to a fork that diverged after
that commit (plus one that committed something to an old fork). That is
based on the time of the commit to the fork, not when it was merged into
the main repo, so it could be fewer, but in any case no more than six
people would need to force-push to their fork(s) if a rewrite was done now.
Also, some of those forks may have already been the subject of PRs that
have been merged, and therefore may be able to be ignored.
___
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/64LIUO4C3EWT45YCTRZLDA7B7IE33IXA/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Re Re: Recent PEP-8 change (Ivan Pozdeev)

2020-07-02 Thread Eric V. Smith

On 7/2/2020 6:49 PM, Rémi Lapeyre wrote:



Le 3 juil. 2020 à 00:32, Ivan Pozdeev via Python-Dev 
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/


[Python-Dev] Re: Re Re: Recent PEP-8 change (Ivan Pozdeev)

2020-07-02 Thread Rémi Lapeyre


> Le 3 juil. 2020 à 00:32, Ivan Pozdeev via Python-Dev  
> 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.

___
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/S7FXOUMKFDAD4M76HPDIQ23H5OLHMGX6/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Re Re: Recent PEP-8 change (Ivan Pozdeev)

2020-07-02 Thread Ivan Pozdeev via Python-Dev
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.


David

---
Date: Thu, 2 Jul 2020 21:33:56 +0300
From: Ivan Pozdeev 
Subject: [Python-Dev] Re: Recent PEP-8 change (Antoine Pitrou)
To: python-dev@python.org
Message-ID: 
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  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/changing-a-commit-message. 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 -- 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/A2XBFOH5WGEOASSXHHKRWEHMZBN625SU/
> Code of Conduct: http://python.org/psf/codeofconduct/ 

> --
> Regards,
> Ivan



___
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/ZZKGBAROR7TR2M7TM4EYSIIHXTUBQB4Y/
Code of Conduct: http://python.org/psf/codeofconduct/
--
Regards,
Ivan
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to