Re: [GIT PULL] MM updates for 7.0-rc1

[Lorenzo Stoakes <lorenzo.stoakes@oracle.com>]

On Thu, Feb 12, 2026 at 05:43:18PM -0800, Linus Torvalds wrote:
> Bah, I keep noticing these things too late, and have to fix them up
> separately, but let's keep edumacating people about this issue...
>
> On Wed, 11 Feb 2026 at 19:23, Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > Lorenzo Stoakes (20):
> >       selftests/mm: remove virtual_address_range test
>
> When removing rules for generating files, PLEASE DO NOT REMOVE THE
> .gitignore ENTRY!
>
> Removing the rule for generating the file does not magically then make
> the file itself disappear in a purple puff of smoke.
>
> That's just not how reality works. The past still exists.
>
> And that means that the old generated file still exists for people,
> and it has *NOT* suddenly become so supremely interesting that people
> should no longer ignore it.
>
> So when you remove a rule for generating a file (or you move it to a
> different directory, or rename it, or whatever), that gitignore entry
> for the old file - or old location - should stay around.
>
> This is more than a "keep git status happy" issue. This has caused
> real issues in the past, where careless developers didn't notice, and
> mistakenly added stale generated binaries to their commits.
>
> No, people shouldn't do that either, and it's a sign of being too
> careless and not looking at what you commit very carefully.
>
> But mistakes happen, and the other side of that argument is that we
> sure as heck shouldn't have files suddenly appear in the source tree
> because they aren't properly ignored any more.
>
> And I'm sure this has happened many times without me noticing, but
> I'll keep harping on this when I _do_ notice, because people need to
> realize that .gitignore files are very much about state being left
> around by the build system.
>
> So you *add* files to the .gitignore files, but you don't remove them.
> Not for a long while, at least - people keep their build trees around
> for months (or years) and don't necessarily clean them up very often.
>
> (And yes, we do have a "remove-stale-files" script that is intended to
> deal with some of this, but it hasn't worked very well, and if you
> want to remove stale files I'd suggest you just do "git clean -dqtx"
> after you are really *really* sure that you don't have any interesting
> files in your source tree that weren't tracked by git)
>
>               Linus

Ack :)