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: <CAHk-=wh5AixGsLeT0qH2oZHKq0FLUTbyTw4qY921L=PwYgoGVw@mail.gmail.com>
Date:   Mon, 27 Feb 2023 09:08:06 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Masahiro Yamada <masahiroy@...nel.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 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.

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

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.

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.

                Linus