Message ID | CAK7LNATJ-3JQ0QQGQ5R+R8aBJEq-tmBL8iBZrbM_4t0zeoYTaw@mail.gmail.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | [GIT,PULL] Kbuild updates for v6.3-rc1 | expand |
On Sun, Feb 26, 2023 at 8:34 AM Masahiro Yamada <masahiroy@kernel.org> wrote: > > Masahiro Yamada (46): > kbuild: add a tool to list files ignored by git > kbuild: make perf-tar*-src-pkg work without relying on git I've pulled this, but I really object to these kinds of silly games. That whole list-gitignored thing should go away, and silly work-arounds for "I don't use git" should likewise just be killed. There's absolutely _zero_ exzcuse for making our build tools more complicated for bad reasons. The "I don't have git" may have been a reason a decade ago. It's *not* a valid reason today. People who insist on using quilt etc should just realize that then they don't get the featrues that git offers. You can't have your cake and eat it too. I do *not* want to see git functionality basically duplicated in some kernel C helper script just because somebody can't be bothered to just use git. Linus
The pull request you sent on Mon, 27 Feb 2023 01:33:25 +0900:
> git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git tags/kbuild-v6.3
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/498a1cf902c31c3af398082d65cf150b33b367e6
Thank you!
Hi Linus, On Mon, Feb 27, 2023 at 3:58 AM Linus Torvalds <torvalds@linux-foundation.org> wrote: > > On Sun, Feb 26, 2023 at 8:34 AM Masahiro Yamada <masahiroy@kernel.org> wrote: > > > > Masahiro Yamada (46): > > kbuild: add a tool to list files ignored by git > > kbuild: make perf-tar*-src-pkg work without relying on git > > I've pulled this, but I really object to these kinds of silly games. > > That whole list-gitignored thing should go away, and silly > work-arounds for "I don't use git" should likewise just be killed. > > There's absolutely _zero_ exzcuse for making our build tools more > complicated for bad reasons. The "I don't have git" may have been a > reason a decade ago. It's *not* a valid reason today. We can say "You must install git on your machine", but IMHO "the kernel must be managed by git" is a too strong assumption because snapshots are delivers as a tarball (e.g. https://www.kernel.org/) I could be wrong, but that is my intent (as in the commit description). > > People who insist on using quilt etc should just realize that then > they don't get the featrues that git offers. > > You can't have your cake and eat it too. > > I do *not* want to see git functionality basically duplicated in some > kernel C helper script just because somebody can't be bothered to just > use git. > > Linus If tar's --exclude-vcs-ignores option had worked correctly, I would not have written such a gitignore parser by myself. When tar implements --exclude-vcs-ignores correctly, I am happy to remove this silly tool. (In turn, tar will end up with a similar gitignore parser as git, though.) -- Best Regards Masahiro Yamada
On Mon, Feb 27, 2023 at 2:10 AM Masahiro Yamada <masahiroy@kernel.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
On Mon, Feb 27, 2023 at 9:08 AM Linus Torvalds <torvalds@linux-foundation.org> wrote: > > 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. Note: I'm perfectly happy to just revert this, but if I have to do it, then pretty much _all_ the packaging changes get reverted, because I'm not going to be able to figure out which parts don't rely on the new broken script. So I'd rather take a more directed revert from you. Or, better yet, just a rewrite to do the right thing (ie "git archive"). Because really - any distro packager had better have the git tree. Linus
On Tue, Feb 28, 2023 at 2:08 AM Linus Torvalds <torvalds@linux-foundation.org> wrote: > > On Mon, Feb 27, 2023 at 2:10 AM Masahiro Yamada <masahiroy@kernel.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
On Tue, Feb 28, 2023 at 2:26 AM Linus Torvalds <torvalds@linux-foundation.org> wrote: > > On Mon, Feb 27, 2023 at 9:08 AM Linus Torvalds > <torvalds@linux-foundation.org> wrote: > > > > 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. > > Note: I'm perfectly happy to just revert this, but if I have to do it, > then pretty much _all_ the packaging changes get reverted, because I'm > not going to be able to figure out which parts don't rely on the new > broken script. > > So I'd rather take a more directed revert from you. Or, better yet, > just a rewrite to do the right thing (ie "git archive"). > > Because really - any distro packager had better have the git tree. OK, let's go this way. Please give me a few days. > > Linus