From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=pass header.i=@linaro.org header.s=google header.b=Exe9YRor; spf=pass (domain: linaro.org, ip: 209.85.128.65, mailfrom: leif.lindholm@linaro.org) Received: from mail-wm1-f65.google.com (mail-wm1-f65.google.com [209.85.128.65]) by groups.io with SMTP; Thu, 04 Apr 2019 20:25:02 -0700 Received: by mail-wm1-f65.google.com with SMTP id q16so5161421wmj.3 for ; Thu, 04 Apr 2019 20:25:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=Ehu7YHbs64KHW/jxdp0mZMedIFdSzWTcm1gZv/VNRlQ=; b=Exe9YRor7KtHb6EN9xbH6wxDrs+8FgduUmgFmwPWYFlqGpe1VNULcDwToln5ram/I7 u7kV1K4/D8/SJ3yGi3GDcWM+02qqD1GNCovjqrI1S4sFpcuHUaD/R+gxzmw3KxgmsBFD uom1nOW4aDE3mtPV0vxkn6yL0RJpSo0G1pmqAn6GNgAfRS05fmfXcrLyY51CilZ4W8AH jB4rcs5e3Brbdbng2c1ZWsD0f47M5KrMlgJJESCYJwkJ+zX27mKCvag5njdrEcBiKsBw OzxB/CMxj/ZCI2ZA7dRGUCBTvfp528QsGy7wTLWwlJ5lmhgRKs1cC2kz++A358cHIrWz PmHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=Ehu7YHbs64KHW/jxdp0mZMedIFdSzWTcm1gZv/VNRlQ=; b=AkqWrQKcHsHpaueceSSzHSlvExlNQCKzKPr5W1SNNeCoB06ORQZrHQXnCQXy4+Wtxa DKUp+naa6C+GUyJPAv9sE+I1CrN/LZnemB43/hAzIsH6axh8RBh7WzfQ5bZp3Tanpt6E PbqtMhWII3qxlezaSp0NwoKRomJVLdl9w4xUs1s2ZlaU5trM3pIkAsfBGgWemB8RhDRL IjJHAjvQ0r00yiuCZjCbAIT5Le+PSFpoKVvFKWk3vAAObkdeuXWSHPMEecrPLe6FujAI Rfla+o5USp9gzeIhY4b7qP0iYhRw/j8XgoOiwQXR0DjRklvaXtmnDqo6jD4gvmKgrzwZ 94eA== X-Gm-Message-State: APjAAAVNJydv3RJNLhFHJ/ymOQ7KJO2cnA2O+l/lWctbFUUVyUrSDTW7 v+RIu0e1sk3mZ+E2g3hxI+2EoA== X-Google-Smtp-Source: APXvYqwhg/vSRdjQsWN8EqmL6OFa66p5lgR7Ia2XhkZpbAHTzZ8qbHpoJbaaVQz9mY+d95hW3PBH4Q== X-Received: by 2002:a1c:244:: with SMTP id 65mr6334002wmc.42.1554434701099; Thu, 04 Apr 2019 20:25:01 -0700 (PDT) Return-Path: Received: from bivouac.eciton.net (bivouac.eciton.net. [2a00:1098:0:86:1000:23:0:2]) by smtp.gmail.com with ESMTPSA id g132sm914850wme.3.2019.04.04.20.24.59 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 04 Apr 2019 20:25:00 -0700 (PDT) Date: Fri, 5 Apr 2019 04:24:58 +0100 From: Leif Lindholm To: "Kinney, Michael D" Cc: Laszlo Ersek , "devel@edk2.groups.io" , Ard Biesheuvel , Andrew Fish Subject: Re: [Patch 0/4] Normalize line endings to CRLF in ARM packages Message-ID: <20190405032458.c7olgdteqwxxr6lh@bivouac.eciton.net> References: <20190403220014.14468-1-michael.d.kinney@intel.com> <20190404035437.qcale3g5qekzb53d@bivouac.eciton.net> <983adf0b-4a30-4a48-b015-502157c712f3@redhat.com> MIME-Version: 1.0 In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Apr 04, 2019 at 05:00:36PM +0000, Kinney, Michael D wrote: > Leif, > > There were a few files when the license change patches > were created that failed PatchCheck.py. > > I am trying to resolve those before the license change > so the license change patches do not have any PatchCheck.py > failures. > > If I do these as part of the license change, then the > change will look larger than just the license change in > these files. > > I prefer to have a separate patch to resolve the line > endings. Oh, it needs to be separate patches. Apologies if I was unclear on that. It should not even form part of the same set. What I meant was that since a substantial bit of churn is about to hit the repository, we might as well go about doing the line ending conversion shortly before or shortly after the license change. If we do it shortly before, we don't need *this* set. If we do it shortly after, we do. > There may be other files in edk2 repo that have mixed > line endings in lines not associated with the license > change itself. We can consider cleaning those up in > a separate series. > > The other option is to abandon these patches to normalize > line endings and allow the license change patches to not > pass PatchCheck.py. > > Which do you prefer? I think it would be completely valid for the license change patches to not pass PatchCheck.py. But why are they not passing? Is it complaining about context lines? Regards, Leif > Thanks, > > Mike > > > > > -----Original Message----- > > From: Laszlo Ersek [mailto:lersek@redhat.com] > > Sent: Thursday, April 4, 2019 3:39 AM > > To: Leif Lindholm ; Kinney, > > Michael D > > Cc: devel@edk2.groups.io; Ard Biesheuvel > > ; Andrew Fish > > > > Subject: Re: [Patch 0/4] Normalize line endings to CRLF > > in ARM packages > > > > On 04/04/19 05:54, Leif Lindholm wrote: > > > Hi Mike, > > > > > > This looks fine. But I did have one thought: > > > If we're just about to touch pretty much every file in > > the tree anyway > > > - can we consider doing the full conversion to native > > line endings at > > > the same time? > > > > > > (This doesn't help the 'git blame' problem, it just > > reminded me.) > > > > The git-blame issue that such a conversion introduces is > > not terrible. > > Let's say you run > > > > git blame -- ArmPkg/Library/GccLto/liblto-arm.s > > > > and it gives you a commit for a specific line you care > > about. Let's call > > that commit C1. > > > > Then you do > > > > git show --color C1 | less > > > > and expect to see the commit message & patch that > > introduced the *logic* > > on that line. But, you only see a "useless" CRLF > > conversion, in that > > commit. So what do you do? Simple, repeat the process as > > follows: > > > > git blame C1^ -- ArmPkg/Library/GccLto/liblto-arm.s > > > > This will assign blame on the lines of the file as the > > file was right > > before C1 changed the line terminators. > > > > > > The problem that I think *is* worse is that, jumping > > about in the git > > history (with git checkout / git bisect), around the > > large conversion > > commit, will expose the user in a brief time to files > > that are both LF > > and CRLF encoded, internally. Therefore, whatever their > > local > > auto-conversion-on-checkout settings are, some commits > > in such a work > > session will not match those settings. > > > > For example, assuming you are on Windows, and set up > > LF-to-CRLF-on-checkout (as you should), then git- > > checkout a commit from > > before the "LF only" conversion commit, you might see > > double CRs. I > > guess. I never tested it. > > > > Thanks > > Laszlo > > > > > > > > > > > > / > > > Leif > > > > > > On Wed, Apr 03, 2019 at 03:00:10PM -0700, Kinney, > > Michael D wrote: > > >> https://bugzilla.tianocore.org/show_bug.cgi?id=1659 > > >> > > >> Normalize line endings to use CRLF to pass > > PatchCheck.py > > >> > > >> Cc: Leif Lindholm > > >> Cc: Ard Biesheuvel > > >> Cc: Laszlo Ersek > > >> Contributed-under: TianoCore Contribution Agreement > > 1.1 > > >> Signed-off-by: Michael D Kinney > > > > >> > > >> Kinney, Michael D (4): > > >> ArmPkg/ArmScmiDxe: Remove non-ASCII character in > > comment > > >> ArmPkg: Normalize line endings to CRLF > > >> ArmVirtPkg: Normalize line endings to CRLF > > >> ArmPlatformPkg: Normalize line endings to CRLF > > >> > > >> .../ArmScmiPerformanceProtocolPrivate.h | 2 > > +- > > >> ArmPkg/Library/ArmSmcLibNull/ArmSmcLibNull.c | 44 > > +- > > >> .../ArmSmcPsciResetSystemLib/AArch64/Reset.S | 60 > > +- > > >> .../AArch64/Reset.asm | 70 > > +- > > >> .../ArmSmcPsciResetSystemLib/Arm/Reset.S | 58 > > +- > > >> .../ArmSmcPsciResetSystemLib/Arm/Reset.asm | 68 > > +- > > >> ArmPkg/Library/CompilerIntrinsicsLib/memset.c | 124 > > ++-- > > >> ArmPkg/Library/GccLto/liblto-aarch64.s | 54 > > +- > > >> ArmPkg/Library/GccLto/liblto-arm.s | 122 > > ++-- > > >> ArmPlatformPkg/Scripts/Ds5/profile.py | 668 > > +++++++++--------- > > >> ArmVirtPkg/Include/Platform/Hidden.h | 56 > > +- > > >> 11 files changed, 663 insertions(+), 663 deletions(- > > ) > > >> > > >> -- > > >> 2.21.0.windows.1 > > >> >