> On 2 Dec 2020, at 20:07, Paul Vinciguerra wrote:
>
>
>
>
>> On Wed, Dec 2, 2020 at 1:12 PM Andrew 👽 Yourtchenko
>> wrote:
>> s/Got doesn’t have/Git doesn’t have/
>>
>> (iPhone autocorrect, sorry)
>>
>> --a
>>
On 2 Dec 2020, at 19:01, Andrew Yourtchenko via lists.fd.io
wro
On Wed, Dec 2, 2020 at 1:12 PM Andrew 👽 Yourtchenko
wrote:
> s/Got doesn’t have/Git doesn’t have/
>
> (iPhone autocorrect, sorry)
>
> --a
>
> On 2 Dec 2020, at 19:01, Andrew Yourtchenko via lists.fd.io gmail@lists.fd.io> wrote:
>
>
>
> On 2 Dec 2020, at 18:21, Paul Vinciguerra
> wrote:
>
s/Got doesn’t have/Git doesn’t have/
(iPhone autocorrect, sorry)
--a
> On 2 Dec 2020, at 19:01, Andrew Yourtchenko via lists.fd.io
> wrote:
>
>
>
>>> On 2 Dec 2020, at 18:21, Paul Vinciguerra
>>> wrote:
>>>
>>
>>
>>
>>> On Wed, Dec 2, 2020 at 10:57 AM Andrew 👽 Yourtchenko
>>> wrot
> On 2 Dec 2020, at 18:21, Paul Vinciguerra wrote:
>
>
>
>
>> On Wed, Dec 2, 2020 at 10:57 AM Andrew 👽 Yourtchenko
>> wrote:
>>
>>
On 2 Dec 2020, at 16:42, Paul Vinciguerra
wrote:
>>>
>>>
>>>
On Wed, Dec 2, 2020 at 5:38 AM Andrew 👽 Yourtchenko
wrote:
>>
On Wed, Dec 2, 2020 at 10:57 AM Andrew 👽 Yourtchenko
wrote:
>
>
> On 2 Dec 2020, at 16:42, Paul Vinciguerra
> wrote:
>
>
>
>
> On Wed, Dec 2, 2020 at 5:38 AM Andrew 👽 Yourtchenko
> wrote:
>
>>
>>
>> > On 2 Dec 2020, at 10:38, Klement Sekera via lists.fd.io > cisco@lists.fd.io> wrote:
>> >
> On 2 Dec 2020, at 16:42, Paul Vinciguerra wrote:
>
>
>
>
>> On Wed, Dec 2, 2020 at 5:38 AM Andrew 👽 Yourtchenko
>> wrote:
>>
>>
>> > On 2 Dec 2020, at 10:38, Klement Sekera via lists.fd.io
>> > wrote:
>> >
>> > I like the idea.
>> >
>> > Regarding maintainer pain:
>> >
>> > Q:
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
On Wed, Dec 2, 2020 at 5:38 AM Andrew 👽 Yourtchenko
wrote:
>
>
> > On 2 Dec 2020, at 10:38, Klement Sekera via lists.fd.io cisco@lists.fd.io> wrote:
> >
> > I like the idea.
> >
> > Regarding maintainer pain:
> >
> > Q: are we now stuck forever with what we have because there will always
>
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
Hi Neale,
The problem with that code in general is that the delayed binding with papi
means that you have to manually ensure that you only reference it *after*
papi has been initialized. The other alternative is to put them in a
lambda or @property, so they are evaluated at the time of use instea
> On 2 Dec 2020, at 10:38, Klement Sekera via lists.fd.io
> wrote:
>
> I like the idea.
>
> Regarding maintainer pain:
>
> Q: are we now stuck forever with what we have because there will always be
> somebody facing some difficulties adopting?
To me it is always a question of cost/benefi
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.
I like the idea.
Regarding maintainer pain:
Q: are we now stuck forever with what we have because there will always be
somebody facing some difficulties adopting?
Thanks,
Klement
> On 2 Dec 2020, at 10:30, Andrew Yourtchenko wrote:
>
>>
>> On 2 Dec 2020, at 10:27, Neale Ranns via lists.fd.
> 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?
> On 2 Dec 2020, at 10:27, Neale Ranns via lists.fd.io
> wrote:
>
>
>
> Hi Paul,
>
> Having to write code to conform to python linting is my number 1 annoyance
> when writing tests. This is my usual hack:
> e = VppEnum.vl_api_tunnel_encap_decap_flags_t
> f = e.TUNNEL_API_ENCAP_DECAP_FLAG
Hi Paul,
Having to write code to conform to python linting is my number 1 annoyance when
writing tests. This is my usual hack:
e = VppEnum.vl_api_tunnel_encap_decap_flags_t
f = e.TUNNEL_API_ENCAP_DECAP_FLAG_ENCAP_COPY_DSCP
I support having an auto-linter. I have no knowledge about what’s av
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
18 matches
Mail list logo
