From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 154C1A09D9; Wed, 11 Nov 2020 16:09:43 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4CFF0137D; Wed, 11 Nov 2020 16:09:40 +0100 (CET) Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by dpdk.org (Postfix) with ESMTP id 70C52F90 for ; Wed, 11 Nov 2020 16:09:39 +0100 (CET) Received: by mail-wr1-f68.google.com with SMTP id d12so2810823wrr.13 for ; Wed, 11 Nov 2020 07:09:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:content-transfer-encoding:user-agent:mime-version; bh=iE9Wx/BEIZZH7F/cU1E0mN7iR2g/0Z0J1/EwAVzpvmg=; b=LwPQiysbPPotPtutb7Pgq91p6n+qMtiOIvyfCj9aNTsw3fnNg28oThY6n+tm9bdICy ivaGUqmHBro5oIIVTDupUY6bT/oLmldFbJKj8Nvzfkq/UELFeAkXC8150tIPim5yhGuS Rkgs/hx06fQhGA07edUqtsvBGzo1f8P+a8viw0aC234tyXmvzyHggaQGg7pYVv7lWbpp QQoaoZEyq+OwEKeIJTmu3e4ubD+RvsFcZ7v4Pzlq/qwkkZhXJ+EyetG3zfonL96qkRsj 1gCkXgsVlGXIqzglO9pnOG7Qd0BqYdHIOz3HOgVhS45jY3IV5CrrxCkEKts2kKtdfwwE hCFQ== X-Gm-Message-State: AOAM531dw8wzLBT9k10J42Uxm3PVU766/L8RHq0R21T8B+7yM9rYC3xb 0sVkO7TDIlv68BvN93Vu/T8= X-Google-Smtp-Source: ABdhPJxxvycNrrkaAfpNX1LIRebdAg32gQ2VfNxCtDGRI6B/BeWFnJwEKCro/A5uED0V5iaf/poyUw== X-Received: by 2002:adf:fd49:: with SMTP id h9mr31936980wrs.115.1605107378115; Wed, 11 Nov 2020 07:09:38 -0800 (PST) Received: from localhost ([88.98.246.218]) by smtp.gmail.com with ESMTPSA id j127sm3185401wma.31.2020.11.11.07.09.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Nov 2020 07:09:37 -0800 (PST) Message-ID: From: Luca Boccassi To: Thomas Monjalon , Dmitry Kozlyuk Cc: dev@dpdk.org, Narcisa Ana Maria Vasile , John Alexander Date: Wed, 11 Nov 2020 15:09:36 +0000 In-Reply-To: <805419dbc589b31f01e8864004a5c2a59dfd6e78.camel@debian.org> References: <20201029225505.30093-1-dmitry.kozliuk@gmail.com> <3042169.36grohAEOo@thomas> <805419dbc589b31f01e8864004a5c2a59dfd6e78.camel@debian.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.30.5-1.1 MIME-Version: 1.0 Subject: Re: [dpdk-dev] [kmods PATCH] windows: normalize line-endings X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Wed, 2020-11-11 at 15:03 +0000, Luca Boccassi wrote: > On Wed, 2020-11-11 at 16:02 +0100, Thomas Monjalon wrote: > > 29/10/2020 23:55, Dmitry Kozlyuk: > > > MSBuild XML files have to use CRLF line-endings, otherwise any change > > > results in the whole file being rewritten with CRLF line-endings by > > > Visual Studio. However, it's inconvenient to have such files checked-= out > > > with CLRF in Unix environments. > > >=20 > > > Add suggested git configuration to top-level README, so that Unix > > > developers don't miss it. Remove .gitattributes, because core.autocrl= f > > > overrides eol=3D attribute. Convert line-endings of the existing file= s in > > > the repository. > >=20 > > It is converted to what? > > You mean all files should have LF endings in the repo? > >=20 > > [...] > > > windows/virt2phys/virt2phys.sln | 54 ++-- > > > windows/virt2phys/virt2phys.vcxproj | 454 ++++++++++++++------------= -- > > > 4 files changed, 259 insertions(+), 258 deletions(-) > >=20 > > The file windows/virt2phys/virt2phys.vcxproj.filters is not converted. > > And I see other stuff to fix, see below. > >=20 > > > +Some Windows files use have to use CRLF line-endings. > >=20 > > "use have to use" -> "have to use" ? > >=20 > > Isn't it automatic to have CRLF on Windows git working tree? > >=20 > > > +Unix developers can configure git to get only LF on checkout: > > > + > > > + git config core.autocrlf input > >=20 > > Isn't it the default? > > If all files have LF, there is nothing to do on Unix. > >=20 > >=20 > > I think more fixes are required as below: >=20 > <..> >=20 > Yes, I second that - those changes are needed too. To clarify, having some options that convert after the fact (clone/checkout) is _not_ a solution - everything needs to be checked in with LF endings only, otherwise automated infrastructure (where setting random configs it's just not an option) will break. --=20 Kind regards, Luca Boccassi