threads / discuss / 64251
Subject: git clean deletes negated pathspec if directory causing data loss
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
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 excludedRe: git clean deletes negated pathspec if directory causing data loss
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
Johannes SchindelinRe: git clean deletes negated pathspec if directory causing data loss
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 excludedI 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 &&
Junio C HamanoRe: git clean deletes negated pathspec if directory causing data loss
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.