[RFC PATCH] selftests/mm: use pattern matching in .gitignore

[RFC PATCH] selftests/mm: use pattern matching in .gitignore

[pratmal]

From: Pratyush Mallick <pratmal@google.com>

The current .gitignore hardcodes each generated test binary by name,
requiring updates every time a new test is added.

Switch to the patten-matching approach similar to KVM:selftests.
Ignore everything by default and then allow source extensions (.c, .h, .sh)
and tracked non-source files.

Signed-off-by: Pratyush Mallick <pratmal@google.com>
---
 tools/testing/selftests/mm/.gitignore | 72 ++++-----------------------
 1 file changed, 11 insertions(+), 61 deletions(-)

diff --git a/tools/testing/selftests/mm/.gitignore b/tools/testing/selftests/mm/.gitignore
index 83ad9454dd9d..92f9205d3996 100644
--- a/tools/testing/selftests/mm/.gitignore
+++ b/tools/testing/selftests/mm/.gitignore
@@ -1,63 +1,13 @@
 # SPDX-License-Identifier: GPL-2.0-only
-cow
-hugepage-mmap
-hugepage-mremap
-hugepage-shm
-hugepage-vmemmap
-hugetlb-madvise
-hugetlb-read-hwpoison
-hugetlb-soft-offline
-khugepaged
-map_hugetlb
-map_populate
-thuge-gen
-compaction_test
-memory-failure
-migration
-mlock2-tests
-mrelease_test
-mremap_dontunmap
-mremap_test
-on-fault-limit
-transhuge-stress
-pagemap_ioctl
-pfnmap
-process_madv
-*.tmp*
-protection_keys
-protection_keys_32
-protection_keys_64
-madv_populate
-uffd-stress
-uffd-unit-tests
-uffd-wp-mremap
-mlock-intersect-test
-mlock-random-test
-virtual_address_range
-gup_test
-va_128TBswitch
-map_fixed_noreplace
-write_to_hugetlbfs
-hmm-tests
-memfd_secret
-soft-dirty
-split_huge_page_test
-ksm_tests
+*
+!/**/
+!*.c
+!*.h
+!*.sh
+!.gitignore
+!Makefile
+!config
+!settings
+#Re-ignore generated files
 local_config.h
-local_config.mk
-ksm_functional_tests
-mdwe_test
-gup_longterm
-mkdirty
-va_high_addr_switch
-hugetlb_fault_after_madv
-hugetlb_madv_vs_map
-mseal_test
-droppable
-hugetlb_dio
-pkey_sighandler_tests_32
-pkey_sighandler_tests_64
-guard-regions
-merge
-prctl_thp_disable
-rmap
+*.mod.c
-- 
2.54.0.rc1.555.g9c883467ad-goog

Re: [RFC PATCH] selftests/mm: use pattern matching in .gitignore

[David Hildenbrand (Arm)]

On 4/21/26 20:30, pratmal@google.com wrote:
> From: Pratyush Mallick <pratmal@google.com>
> 
> The current .gitignore hardcodes each generated test binary by name,
> requiring updates every time a new test is added.
> 
> Switch to the patten-matching approach similar to KVM:selftests.
> Ignore everything by default and then allow source extensions (.c, .h, .sh)
> and tracked non-source files.

That looks pretty nice. Any reason for the RFC? (iow, are you unsure about some
side-effects?)

-- 
Cheers,

David

Re: [RFC PATCH] selftests/mm: use pattern matching in .gitignore

[pratmal]

On 4/22/26 18:04, David Hildenbrand (Arm) wrote:
> On 4/21/26 20:30, pratmal@google.com wrote:
>> From: Pratyush Mallick <pratmal@google.com>
>> 
>> The current .gitignore hardcodes each generated test binary by name,
>> requiring updates every time a new test is added.
>> 
>> Switch to the patten-matching approach similar to KVM:selftests.
>> Ignore everything by default and then allow source extensions (.c, .h, .sh)
>> and tracked non-source files.
> That looks pretty nice. Any reason for the RFC? (iow, are you unsure about some
> side-effects?)

Exactly that. I verified that the build works fine, however I sent it 
as an RFC just to be cautious. I wanted to get some feedback in case this 
might introduce some unwanted behavior that I'm not aware of. :)

Thanks,
Pratyush

Re: [RFC PATCH] selftests/mm: use pattern matching in .gitignore

[pratmal]

(Resending to correct David's email address. Apologies for the noise!)

On 4/22/26 18:04, David Hildenbrand (Arm) wrote:
> On 4/21/26 20:30, pratmal@google.com wrote:
>> From: Pratyush Mallick <pratmal@google.com>
>> 
>> The current .gitignore hardcodes each generated test binary by name,
>> requiring updates every time a new test is added.
>> 
>> Switch to the patten-matching approach similar to KVM:selftests.
>> Ignore everything by default and then allow source extensions (.c, .h, .sh)
>> and tracked non-source files.
> That looks pretty nice. Any reason for the RFC? (iow, are you unsure about some
> side-effects?)

Exactly that. I verified that the build works fine, however I sent it 
as an RFC just to be cautious. I wanted to get some feedback in case this 
might introduce some unwanted behavior that I'm not aware of. :)

Thanks,
Pratyush