git clean deletes negated pathspec if directory causing data loss

git clean deletes negated pathspec if directory causing data loss

[Devste Devste]

I am using:
git version 2.51.0.windows.1

Run:
echo .idea/dictionaries >> .gitignore
mkdir -p .idea/dictionaries
touch .idea/dictionaries/foo.xml
git clean -f -f -d -X --dry-run -- ':!/.idea/dictionaries' ':*.rej' ':/*/*.log'

Outputs:
Would remove .idea/dictionaries/

No matter how you specify the pathspec (':!.idea',...) it always wants
to delete the .idea/dictionaries directory, even though it does not
contain any .rej or .log files and is explicitly set to excluded

Re: git clean deletes negated pathspec if directory causing data loss

[Devste Devste]

Just to clarify: it's not about the negation not working, but clean
ignores the pathspec for ignored directories completely. I only want
to delete .rej and .log files, but it will also delete gitignored
directories (that may or may not contain any .rej or .log files)

On Sun, 5 Oct 2025 at 13:27, Devste Devste <devstemail@gmail.com> wrote:
>
> I am using:
> git version 2.51.0.windows.1
>
> Run:
> echo .idea/dictionaries >> .gitignore
> mkdir -p .idea/dictionaries
> touch .idea/dictionaries/foo.xml
> git clean -f -f -d -X --dry-run -- ':!/.idea/dictionaries' ':*.rej' ':/*/*.log'
>
> Outputs:
> Would remove .idea/dictionaries/
>
> No matter how you specify the pathspec (':!.idea',...) it always wants
> to delete the .idea/dictionaries directory, even though it does not
> contain any .rej or .log files and is explicitly set to excluded

Re: git clean deletes negated pathspec if directory causing data loss

[Devste Devste]

Anyone?

On Sun, 5 Oct 2025 at 13:33, Devste Devste <devstemail@gmail.com> wrote:
>
> Just to clarify: it's not about the negation not working, but clean
> ignores the pathspec for ignored directories completely. I only want
> to delete .rej and .log files, but it will also delete gitignored
> directories (that may or may not contain any .rej or .log files)
>
> On Sun, 5 Oct 2025 at 13:27, Devste Devste <devstemail@gmail.com> wrote:
> >
> > I am using:
> > git version 2.51.0.windows.1
> >
> > Run:
> > echo .idea/dictionaries >> .gitignore
> > mkdir -p .idea/dictionaries
> > touch .idea/dictionaries/foo.xml
> > git clean -f -f -d -X --dry-run -- ':!/.idea/dictionaries' ':*.rej' ':/*/*.log'
> >
> > Outputs:
> > Would remove .idea/dictionaries/
> >
> > No matter how you specify the pathspec (':!.idea',...) it always wants
> > to delete the .idea/dictionaries directory, even though it does not
> > contain any .rej or .log files and is explicitly set to excluded

Re: git clean deletes negated pathspec if directory causing data loss

[Johannes Schindelin]

Hi Devste,

On Wed, 29 Oct 2025, Devste Devste wrote:

> Anyone?
> 
> On Sun, 5 Oct 2025 at 13:33, Devste Devste <devstemail@gmail.com> wrote:
> >
> > Just to clarify: it's not about the negation not working, but clean
> > ignores the pathspec for ignored directories completely. I only want
> > to delete .rej and .log files, but it will also delete gitignored
> > directories (that may or may not contain any .rej or .log files)
> >
> > On Sun, 5 Oct 2025 at 13:27, Devste Devste <devstemail@gmail.com> wrote:
> > >
> > > I am using:
> > > git version 2.51.0.windows.1
> > >
> > > Run:
> > > echo .idea/dictionaries >> .gitignore
> > > mkdir -p .idea/dictionaries
> > > touch .idea/dictionaries/foo.xml
> > > git clean -f -f -d -X --dry-run -- ':!/.idea/dictionaries' ':*.rej' ':/*/*.log'
> > >
> > > Outputs:
> > > Would remove .idea/dictionaries/
> > >
> > > No matter how you specify the pathspec (':!.idea',...) it always wants
> > > to delete the .idea/dictionaries directory, even though it does not
> > > contain any .rej or .log files and is explicitly set to excluded

I can reproduce, both on Windows and on Linux. (Note that I prefer the
`:(exclude).idea/directories` form because it is more descriptive and it
also does not run afoul of Bash's special handling of the exclamation
point).

Unfortunately, the code in question is quite convoluted, and the intention
is also not quite clear. The main problem seems to be to agree on what
`-X` should mean in conjunction with `:(exclude)`.

One interpretation (which I assume is yours): When `-X` implicitly adds
items to be removed, `:(exclude)` should be able to remove them again.

The interpretation of the authors of the logic I see in the source code,
though, seem to treat the `-X` as a completely separate mechanism that
overrides whatever `:(exclude)` may be specified on the command-line.

Honestly, I am unsure how to resolve this, especially given that the
overall architecture of `dir.c` (which contains the business logic of
exclusions specified e.g. by `.gitignore) seems to have grown so
organically as to result in a complex, hard-to-reason-about state.

In case the Git maintainer (whose call it is, ultimately, on which side to
land regarding above-mentioned options) sides with your interpretation,
here is a patch to add a regression test demonstrating your use case:

-- snipsnap --
diff --git a/t/t7300-clean.sh b/t/t7300-clean.sh
index 6f16f389319..6bc7c42a572 100755
--- a/t/t7300-clean.sh
+++ b/t/t7300-clean.sh
@@ -362,6 +362,14 @@ test_expect_success 'git clean -d -X with ignored tracked directory' '
 
 '
 
+test_expect_failure 'git clean -d -X with :(exclude)' '
+	test_when_finished "rm -rf build" &&
+	mkdir -p build &&
+	touch build/lib.so &&
+	git clean -d -X -- ":(exclude)build" &&
+	test_path_is_file build/lib.sh
+'
+
 test_expect_success 'clean.requireForce defaults to true' '
 
 	git config --unset clean.requireForce &&

Re: git clean deletes negated pathspec if directory causing data loss

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> In case the Git maintainer (whose call it is, ultimately, on which side to
> land regarding above-mentioned options) sides with your interpretation,
> here is a patch to add a regression test demonstrating your use case:

Thanks for an opinion.

As "git clean -X" is not really "my thing", not in the sense that I
did not write it (I didn't, except for code clean-ups) but in the
sense that I see no good use case for the option and I rarely use it
myself, as long as its behaviour can be "explained", like you just
did, I do not have preference myself, and no strong motivation to
advocate changing it, risking potential disruption on existing
users.