linux-kernel - Re: [GIT PULL] Kbuild updates for v6.3-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAK7LNAQj9=yzb3C0OdTq=6MPr4SZE=PBXaZY7xPMbti1Fe7n6g@mail.gmail.com>
Date:   Wed, 1 Mar 2023 01:19:54 +0900
From:   Masahiro Yamada <masahiroy@...nel.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>
Subject: Re: [GIT PULL] Kbuild updates for v6.3-rc1

On Tue, Feb 28, 2023 at 2:08 AM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> On Mon, Feb 27, 2023 at 2:10 AM Masahiro Yamada <masahiroy@...nel.org> wrote:
> >
> > If tar's --exclude-vcs-ignores option had worked correctly,
> > I would not have written such a gitignore parser by myself.
>
> But that thing is *WRONG*.
>
> Seriously. It's fundamentally wrong.
>
> The thing is, you don't even seem to understand how gitignores work.
>
> A gitignore pattern doesn't actually mean "this path does not exist in the VCS".
>
> It means "git will ignore this path for unknown files".
>
> And that's a *big* difference.


Of course, I know this difference.

I wrote it in the commit description of
5c3d1d0abb12a6915d0f43233837053945621a89

Please read it closely.





We are talking past each other due to the disagreement
about　what the source code means.

You think "what is committed in the VCS is the source code"
in other words, files in "HEAD" are sources.



I think "what exists in the source tree is the source code"
that is, files in the "working tree" are sources.

Of course, the working tree contains a lot of build artifacts, hence
the list-gitignored tool excludes them.




>
> That "for unknown files" means that *known* files can still match the pattern.

Yes,

'git ls-files -i -c --exclude-per-directory=.gitignore'

lists those files. None of them is needed for building the kernel,
and if we want, it is easy to fix .gitignore files.


>
> And that is actually a perfectly valid pattern, and is very much by
> design. You can say "ignore unknown *.o files", but still actually add
> one explicitly to a git repository, if there is some special case.
> There's nothing wrong with it.
>
> But the way you have done things, it now is actively wrong.
>
> We are *not* adding complexity for no good reason, particularly when
> said complexity is fundamentally *broken*.
>
> Yes, we export the kernel as a tar-file. But that's for people who
> just don't want to deal with the full deal, and even that is partly
> for legacy reasons that aren't necessarily all that true any more.
>
> I suspect that by now, there are probably _more_ people used to git
> than there are people who are still used to the "tar-files and
> patches" workflow.

I do not know.
We are discussing from upstream developers' point of view,
not from packagers' point of view.



>
> So here's the simple rule: if the packaging people can't be bothered
> to use "gti archive" to make their packages, then they had better just
> do a "make clean" first (or, better yet, do "git clean -dqfx" to
> really clean up, because "make clean" isn't 100% reliable either).
>
> We don't add more broken infrastructure to deal with broken workflows.
> Just do the right thing.
>
> Or if package managers want to do their own thing, then they can damn
> well do it in their own broken systems, not adding a completely broken
> script to the kernel.

Fair enough.


>
>                 Linus


--
Best Regards
Masahiro Yamada