I agree. During this discourse, I got an email about a
> trailing whitespace in a recent commit of mine.
Default config in Ubuntu highlights it in bright red background, so it looks
ugly.
It also looks quite prominent in gerrit review as well. If your tooling doesn’t
deal with it, you might wa
gt;> —a
>>>
>>> >
>>> > Thanks,
>>> > Klement
>>> >
>>> >>> On 2 Dec 2020, at 10:30, Andrew Yourtchenko
>>> wrote:
>>> >>>
>>> >>>
>>> >>>> On 2 Dec 20
ally yet another issue that I haven’t mentioned yet.
>
> And, again, considering the biggest annoyance for everyone today is E501, it
> smells like we are discussing the usage of the nuclear charge for making a
> backyard BBQ...
>
> —a
>
>>> —a
>>>
>&g
gt;> >
>>>> > Thanks,
>>>> > Klement
>>>> >
>>>> >>> On 2 Dec 2020, at 10:30, Andrew Yourtchenko wrote:
>>>> >>>
>>>> >>>
>>>> >>>> On 2 Dec 2020, at 10:27, Neale Ranns via list
t; f = e.TUNNEL_API_ENCAP_DECAP_FLAG_ENCAP_COPY_DSCP
>> >>
>> >> +1 E501 specifically being a massive annoyance and having to use the
>> exact same hack - if you use the flags multiple times it might forcing the
>> somewhat better readability, but then one still has t
as to do f1, f2 and
>> >> later combine *them*, which definitely doesn’t help understanding of the
>> >> code by any later reader since now they have to keep these mappings in
>> >> the head.
>> >>
>> >> —a
>> >>
>&g
Yes, but still you need to submit patch with whitespace changes.
Point is that that makes cherry-picking, back-porting PITA.
—
Damjan
> On 02.12.2020., at 16:02, Paul Vinciguerra wrote:
>
> Hi Damjan.
>
> From their docs.
> Migrating your code style without ruining git blame
> A long-standin
gt; —a
> >>
> >>>
> >>> I support having an auto-linter. I have no knowledge about what’s
> available, so I defer to your choice. All I ask is that it works 😉 i.e.
> you don’t have to pepper code with /* *HERE-BE-DRAGONS* */
> >>>
> >>> IIUC
Copying the list this time ;)
> Has to be 2.23 or greater.
>
> On Wed, Dec 2, 2020 at 4:15 AM Andrew 👽 Yourtchenko
> 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 s
Hi Damjan.
>From their docs.
Migrating your code style without ruining git blame
A long-standing argument against moving to automated code formatters like
*Black* is that the migration will clutter up the output of git blame. This
was a valid argument, but since Git version 2.23, Git natively
sup
aul Vinciguerra <
> pvi...@vinciconsulting.com>
> *Date: *Tuesday 1 December 2020 at 23:56
> *To: *vpp-dev
> *Subject: *[vpp-dev] replacing make test-checkstyle with black
>
>
>
> I'd like to propose that we make it easier for everyone by adding black
> [0] as a p
/* *HERE-BE-DRAGONS* */
>>>
>>> IIUC the plan post 21.01 is to upgrade our default linux distro to 20.04,
>>> that brings git 2.25 (at least that’s what my VM has, but maybe I put that
>>> there for recent gerrit up-revs…)
>>>
>>> /neale
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.
t;> there for recent gerrit up-revs…)
>>
>> /neale
>>
>> From: on behalf of Paul Vinciguerra
>>
>> Date: Tuesday 1 December 2020 at 23:56
>> To: vpp-dev
>> Subject: [vpp-dev] replacing make test-checkstyle with black
>>
>> I&#x
> On 01.12.2020., at 23:55, Paul Vinciguerra wrote:
>
> 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.
Can you please explain how new version of git helps here?
of Paul Vinciguerra
>
> Date: Tuesday 1 December 2020 at 23:56
> To: vpp-dev
> Subject: [vpp-dev] replacing make test-checkstyle with black
>
> I'd like to propose that we make it easier for everyone by adding black [0]
> as a pre-commit hook. Black will automatica
recent gerrit up-revs…)
/neale
From: on behalf of Paul Vinciguerra
Date: Tuesday 1 December 2020 at 23:56
To: vpp-dev
Subject: [vpp-dev] replacing make test-checkstyle with black
I'd like to propose that we make it easier for everyone by adding black [0] as
a pre-commit hook. Black
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
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 na
19 matches
Mail list logo
