# [RFC] git clean: add persistent exclude patterns

1 messages from 2026-09-06 to 2026-09-06. Participants: Nicolas Jeanmonod.
Thread: https://gitlist.dev/t/66280

## Nicolas Jeanmonod, 2026-09-06 13:56

Subject: [RFC] git clean: add persistent exclude patterns
Message-ID: <CA+35gGbO4_Yy=vZ+nZSLBorRnZMyBsr-Okn+rh0yrXiEWy=BFg@mail.gmail.com>

```
Hi,

I would like to propose a way to configure persistent exclusion
patterns for `git clean`.

Currently, `git clean` supports:

ˋˋˋ
-e <pattern>
--exclude=<pattern>
ˋˋˋ

and these exclusions are deliberately still honored when `-x` is used.

For example:

ˋˋˋ
git clean -fdx -e '*nogitclean*'
ˋˋˋ

will remove ignored files while preserving paths matching `*nogitclean*`.

What seems to be missing is a way to make such exclusions persistent.
A possible configuration could be:

ˋˋˋ
[clean]
    exclude = *nogitclean*
ˋˋˋ

or, for multiple patterns:

ˋˋˋ
[clean]
    exclude = *nogitclean*
    exclude = important-local-data/
ˋˋˋ

which could be configured globally or per repository:

ˋˋˋ
git config --global --add clean.exclude '*nogitclean*'
ˋˋˋ

The intended semantics would be the same as if the configured patterns
had been supplied using `git clean -e`: in particular, they would
continue to protect matching paths when `git clean -x` is used.

The use case is slightly different from `.gitignore` or
`core.excludesFile`. Those answer the question "which files should Git
normally ignore?", whereas this configuration would answer "which
untracked paths should `git clean` never remove by default, even when
cleaning ignored files?"

One concrete use case is keeping local metadata or other irreplaceable
directories inside a working tree while still being able to use `git
clean -fdx` for build products. Such directories may intentionally be
ignored by Git, but `-x` currently removes them unless the
corresponding `-e` option is remembered every time.

An alternative design could be a dedicated file such as
`clean.excludesFile`, but a multi-valued `clean.exclude` setting seems
simpler and maps directly to the existing `-e` option.

Would such a configuration be considered useful and consistent with
the intended semantics of `git clean`?

Thanks,
Nicolas

```