Re: [GIT PULL] x86/entry for 7.0-rc1

[Linus Torvalds]

On Tue, 10 Feb 2026 at 20:24, Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> So .gitignore files should only add new names, not remove old names.
>
> Sure, _eventually_ the stale entries can be removed, but not in some
> kind of immediate short timeframe.

Side note: it might be worth thinking about naming generated files
very explicitly.

Out generated headers go into a subdirectory of their own, which
solves the problem for them. But that's inconvenient when you want to
have just a random one-off thing.

Maybe it would be good to just make those files *very* explicit, and
name them something very clearly different. Like always using the
filename pattern 'xyz.generated.[ch]' or something like that.

Then we could just add the '*.generated.[ch]' pattern to the top-level
.gitignore and not have to worry about at least those files.

This is not a huge issue, and most releases don't have this at all.

But it just so happens that not having seen this for a good long
while, the current merge window has now had two very different "people
don't ignore generated files properly".

Don't people use 'git status' (or look at the status that gets printed
out by a number of other git commands)?

I suspect one issue is that people who *know* they moved the file may
think "oh, I moved that file, I'll just remove that left-over turd
too". So the people who move files aren't confused and don't think
it's a big deal.

But they don't realize that for other people - the people who *didn't*
move the file and have no idea what that file is - are much more
likely to be confused and go "Why did that file suddenly show up".

Because those other people may not even realize that it's a generated
file because they were never really aware of it before.

              Linus