I agree. Smarter "git blame” will not help with massive whitespace change.
>From a perspective of non-python coder I really don’t like where this is going >on. Every time I tried to make simple change in tests ended up with dealing with un-readable python code and PEPs - whatever that means. VPP is C project and we should respect the fact that don’t all C coders are masters in python. So please keep it simple…. — Damjan > On 02.12.2020., at 10:15, Andrew Yourtchenko <ayour...@gmail.com> wrote: > > Can git in any version ignore the massive white space changes while > cherry-picking / merging? > If not - this sounds like a *massive* inconvenience to anyone not sitting on > the head of master, which is a lot of folks. At least that is why it’s still > on my WIP to deal with the C code indent... big white space-changing changes > are a *massive* pain to deal with for any maintainer. > > Also, 88 is not much bigger than 80, and won’t solve the particular case > mentioned - you will still need to chop that 97 char line into smaller one.. > > So: What do you and others think of an alternative of just adding E501 to the > existing “ignore” list for the current formatter and moving on ? > > --a > >> On 1 Dec 2020, at 23:56, Paul Vinciguerra <pvi...@vinciconsulting.com> wrote: >> >> >> I'd like to propose that we make it easier for everyone by adding black [0] >> as a pre-commit hook. Black will automatically reformat your file to a git >> friendly, pep-8 friendly file. >> For those interested in the details, it moves to a line length of 88, which >> helps us out with the lengthy VppEnum names we have. We can keep it at 80 >> if the community objects. >> I can't do anything about: >> /vpp/build-root/build-test/src/test_ipsec_esp.py:504:89: E501 line too >> long (97 > 88 characters) >> >> VppEnum.vl_api_tunnel_encap_decap_flags_t.TUNNEL_API_ENCAP_DECAP_FLAG_ENCAP_COPY_DSCP >> ;) >> >> For those who want more details in the changes, see the black code style [1] >> >> Saving time around python linting is the #1 request I have had from the >> community. >> >> This is a MASSIVE whitespace change. git blame can ignore whitespace >> changes starting in git 2.23. >> >> The question is whether the community wants to upgrade their version of git >> to ignore this change with git blame, in exchange for not having to manually >> lint/fix their files. >> >> Thoughts? >> >> [0] https://github.com/psf/black <https://github.com/psf/black> >> [1] https://github.com/psf/black/blob/master/docs/the_black_code_style.md >> <https://github.com/psf/black/blob/master/docs/the_black_code_style.md> >> >> > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18214): https://lists.fd.io/g/vpp-dev/message/18214 Mute This Topic: https://lists.fd.io/mt/78647163/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
