threads / discuss / 64761

Feat. req.: add a flag to `git clean` to also remove ignored nested repositories

Subject: Feat. req.: add a flag to `git clean` to also remove ignored nested repositories

## tl;dr

3 messages between Jan 9, 2026 and Jan 16, 2026.

replies: 2people: 2as markdown or json

Simon Cheng· Jan 9, 2026, 03:50 UTC · lore

Currently, running `git clean -dxf` on a repository that includes another repository under an ignored path would skip said repository:

$ git clean -dxf Removing foo Skipping repository ignored-path/repo Removing bar

This is to request the addition of a new flag to allow altering this behaviour, i.e. to make `git clean` remove those repositories too.

For me, this feature is relevant for building `*-git` packages from the AUR, for example https://aur.archlinux.org/packages/paru-git. By default `makepkg` would clone the source repo into `./src/NAME`, which creates the aforementioned condition. Without such an option on `git clean`, cleanup after build is rather complicated.

Thanks and regards, Simon Cheng

brian m. carlson· Jan 9, 2026, 13:18 UTC · re: Simon Cheng · lore

Re: Feat. req.: add a flag to `git clean` to also remove ignored nested repositories

On 2026-01-09 at 03:50:30, Simon Cheng wrote:

Show 16 quoted lines

> Currently, running `git clean -dxf` on a repository that includes
> another repository under an ignored path would skip said repository:
> 
> $ git clean -dxf
> Removing foo
> Skipping repository ignored-path/repo
> Removing bar
> 
> This is to request the addition of a new flag to allow altering this
> behaviour, i.e. to make `git clean` remove those repositories too.
> 
> For me, this feature is relevant for building `*-git` packages from
> the AUR, for example https://aur.archlinux.org/packages/paru-git. By
> default `makepkg` would clone the source repo into `./src/NAME`, which
> creates the aforementioned condition. Without such an option on `git
> clean`, cleanup after build is rather complicated.

Does this work if you use `git clean -dxff` (that is, with a second `-f` flag)? I do often clean up ignored repositories that way (and it's documented to do that in the manual page), but I'm not sure if you're maybe doing something a little different from my workflow.

If that _doesn't_ work for you, would you mind creating a quick shell script to demonstrate the problem that you're seeing so that we could provide better advice?

-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

Simon Cheng· Jan 16, 2026, 05:16 UTC · re: brian m. carlson · lore

Re: Feat. req.: add a flag to `git clean` to also remove ignored nested repositories

Ah yes that's exactly what I need, thanks a lot. Pebkac moment for me sorry.

I must say though, the discoverability of this "double -f" behaviour can be improved. Maybe the "nested repository skipped" message can include a hint? Something like this I imagine:

Skipping repository ignored-path/repo (pass a second `-f` to remove)

Wdyt?

On Fri, 9 Jan 2026 at 21:18, brian m. carlson <sandals@crustytoothpaste.net> wrote:

Show 30 quoted lines

>
> On 2026-01-09 at 03:50:30, Simon Cheng wrote:
> > Currently, running `git clean -dxf` on a repository that includes
> > another repository under an ignored path would skip said repository:
> >
> > $ git clean -dxf
> > Removing foo
> > Skipping repository ignored-path/repo
> > Removing bar
> >
> > This is to request the addition of a new flag to allow altering this
> > behaviour, i.e. to make `git clean` remove those repositories too.
> >
> > For me, this feature is relevant for building `*-git` packages from
> > the AUR, for example https://aur.archlinux.org/packages/paru-git. By
> > default `makepkg` would clone the source repo into `./src/NAME`, which
> > creates the aforementioned condition. Without such an option on `git
> > clean`, cleanup after build is rather complicated.
>
> Does this work if you use `git clean -dxff` (that is, with a second `-f`
> flag)?  I do often clean up ignored repositories that way (and it's
> documented to do that in the manual page), but I'm not sure if you're
> maybe doing something a little different from my workflow.
>
> If that _doesn't_ work for you, would you mind creating a quick shell
> script to demonstrate the problem that you're seeing so that we could
> provide better advice?
> --
> brian m. carlson (they/them)
> Toronto, Ontario, CA