Re: Unexpected recursion in 'git rm'

From: Matt Hunter <m@lfurio.us>
Date: Jul 3, 2026, 13:04 UTC
Message-ID: <DJOYGY682OLT.1TPZHGTA5EMQQ@lfurio.us>
In-Reply-To: <1978773121.20260703123754@gmail.com>

On Fri Jul 3, 2026 at 5:37 AM EDT, Евгений Плискин wrote:

Show 7 quoted lines

>> 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.