Unexpected recursion in 'git rm'

Unexpected recursion in 'git rm'

[Евгений Плискин]

Hello.

The following git command does recurse directories as contrary to the reference (https://git-scm.com/docs/git-rm):

    git rm -n *.json

Without directory specification before '*.json' this command is not expected to recurse directories, but it really does.

git version 2.55.0.windows.1

-- 
Regards,
Eugene Pliskin                          mailto:eugene.pliskin@gmail.com

Re: Unexpected recursion in 'git rm'

[Matt Hunter]

On Thu Jul 2, 2026 at 3:49 AM EDT, Евгений Плискин wrote:
> Hello.
>
> The following git command does recurse directories as contrary to the reference (https://git-scm.com/docs/git-rm):
>
>     git rm -n *.json
>
> Without directory specification before '*.json' this command is not expected to recurse directories, but it really does.
>
> git version 2.55.0.windows.1

Hi - I threw a quick test repo together, but did not see the result you
describe.  Could you produce a script or series of commands to reproduce
the problem?

Re: Unexpected recursion in 'git rm'

[Patrick Steinhardt]

Hi,

On Thu, Jul 02, 2026 at 10:49:10AM +0300, Евгений Плискин wrote:
> Hello.
> 
> The following git command does recurse directories as contrary to the
> reference (https://git-scm.com/docs/git-rm):
> 
>     git rm -n *.json
> 
> Without directory specification before '*.json' this command is not
> expected to recurse directories, but it really does.

This is expected behaviour, as the argument to git-rm(1) is a pathspec,
and "*" matches directory separators by default, see also gitglossary(7)
under "pathspec":

  • the pathspec up to the last slash represents a directory prefix. The
    scope of that pathspec is limited to that subtree.

  • the rest of the pathspec is a pattern for the remainder of the
    pathname. Paths relative to the directory prefix will be matched
    against that pattern using fnmatch(3); in particular, * and ? can
    match directory separators.

  For example, Documentation/*.jpg will match all .jpg files in the
  Documentation subtree, including Documentation/chapter_1/figure_1.jpg.

Could you maybe clarify which part of git-rm(1) made you think that this
wouldn't happen?

Thanks!

Patrick

Re: Unexpected recursion in 'git rm'

[Phillip Wood]

On 03/07/2026 09:31, Patrick Steinhardt wrote:
> On Thu, Jul 02, 2026 at 10:49:10AM +0300, Евгений Плискин wrote:
>> Hello.
>>
>> The following git command does recurse directories as contrary to the
>> reference (https://git-scm.com/docs/git-rm):
>>
>>      git rm -n *.json
>>
>> Without directory specification before '*.json' this command is not
>> expected to recurse directories, but it really does.

Are there any ".json" files in the directory where you're running this? 
As the glob is not quoted, I think maybe what is happening is that there 
are no matching files in the current directory so the shell is not 
expanding the glob as you expect and is passing it to git which treats 
it as Patrick explains below.

Thanks

Phillip

> This is expected behaviour, as the argument to git-rm(1) is a pathspec,
> and "*" matches directory separators by default, see also gitglossary(7)
> under "pathspec":
> 
>    • the pathspec up to the last slash represents a directory prefix. The
>      scope of that pathspec is limited to that subtree.
> 
>    • the rest of the pathspec is a pattern for the remainder of the
>      pathname. Paths relative to the directory prefix will be matched
>      against that pattern using fnmatch(3); in particular, * and ? can
>      match directory separators.
> 
>    For example, Documentation/*.jpg will match all .jpg files in the
>    Documentation subtree, including Documentation/chapter_1/figure_1.jpg.
> 
> Could you maybe clarify which part of git-rm(1) made you think that this
> wouldn't happen?
> 
> Thanks!
> 
> Patrick
> 

Re: Unexpected recursion in 'git rm'

[Patrick Steinhardt]

Adding the mailing list back into Cc.

On Fri, Jul 03, 2026 at 12:34:14PM +0300, Евгений Плискин wrote:
> > This is expected behaviour, as the argument to git-rm(1) is a pathspec, and "*" matches directory separators by default, see also gitglossary(7) under "pathspec":
> >   • the pathspec up to the last slash represents a directory prefix. The  scope of that pathspec is limited to that subtree.
> >   • the rest of the pathspec is a pattern for the remainder of the pathname. Paths relative to the directory prefix will be matched against that pattern using fnmatch(3); in particular, * and ? can match directory separators.
> >   For example, Documentation/*.jpg will match all .jpg files in the  Documentation subtree, including Documentation/chapter_1/figure_1.jpg.
> > Could you maybe clarify which part of git-rm(1) made you think that this wouldn't happen?
> 
> Thank you for your reply. I believe you are correct.
> 
> I have made more research and found a way to remove files in current directory only without recursion into subdirectories:
>      git rm -n ':(glob)*.json'

Yup, that wouldn't cross directory separators indeed.

Patrick

Re: Unexpected recursion in 'git rm'

[Matt Hunter]

On Fri Jul 3, 2026 at 5:37 AM EDT, Евгений Плискин wrote:
>> Hi - I threw a quick test repo together, but did not see the result you describe.  Could you produce a script or series of commands to reproduce the problem?
> Hi. Thank you for your reply. 
> I was advised meantime that indeed this behaviour is expected:
>
> This is expected behaviour, as the argument to git-rm(1) is a pathspec,
> and "*" matches directory separators by default, see also gitglossary(7)
> under "pathspec":

Yup, I see that now, and that was the difference maker in my test.  I
had json files in the directory I was working, as well as at nested
paths.  My (non-windows) shell globbed to pass just the upper files.

To address Patrick's question in <akdzSHrJ4DfdUWoS@pks.im>:

> Could you maybe clarify which part of git-rm(1) made you think that this
> wouldn't happen?

I'll say that I _don't_ think the man page is unclear in this regard
(having given it a look just now).  To me, this is just one of the
aspects of git that is integrated with its unix counterpart well enough
(git-rm vs. rm) that you can forget the finer details like this fairly
easily.

And since the command is so straightforward, I couldn't tell you the
last time I pulled up git-rm(1) as a reference.

Re: Unexpected recursion in 'git rm'

[Mikael Magnusson]

On Thu, Jul 2, 2026 at 9:51 AM Евгений Плискин <eugene.pliskin@gmail.com> wrote:
>
> Hello.
>
> The following git command does recurse directories as contrary to the reference (https://git-scm.com/docs/git-rm):
>
>     git rm -n *.json
>
> Without directory specification before '*.json' this command is not expected to recurse directories, but it really does.
>
> git version 2.55.0.windows.1

I can't see any formulation in the manpage reference that suggests it
wouldn't recurse, though you might overall get less surprised if you
set the failglob option in bash. Then the shell would notice *.json
has no matches, and you'd have to say git rm -n '*.json' to let git
process the glob instead of the shell. See also
https://git-scm.com/docs/gitglossary (as referenced from the git-rm
page) which says:

  the rest of the pathspec is a pattern for the remainder of the pathname.
  Paths relative to the directory prefix will be matched against that
  pattern using fnmatch(3); in particular, * and ? can match directory
  separators.

-- 
Mikael Magnusson

Re: Unexpected recursion in 'git rm'

[Junio C Hamano]

Mikael Magnusson <mikachu@gmail.com> writes:

> ..., though you might overall get less surprised if you
> set the failglob option in bash.

Excellent suggestion.