Re: "git rm" seems to do recursive removal even without "-r"

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 10, 2017, 08:58 UTC
Message-ID: <xmqqpo9vpeg3.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <alpine.LFD.2.21.1710100432220.16182@localhost.localdomain>

"Robert P. J. Day" <rpjday@crashcourse.ca> writes:

Show 12 quoted lines

> underlying weirdness. but it still doesn't explain the different
> behaviour between:
>
>   $ git rm -n 'Makefile*'
>   $ git rm -n '*Makefile'
>
> in the linux kernel source tree, the first form matches only the
> single, top-level Makefile, while the second form gets *all* of them
> recursively, even though those globs should be equivalent in terms of
> matching all files named "Makefile".
>
>   am i misunderstanding something?

We are matching what Git cares/knows about aka "the paths in the index" to pathspec patterns.

What are these paths in the index? In Linux kernel sources, there are quite a many but here are examples that are enough to explain the above:

	Makefile
        COPYING
	fs/Makefile
	fs/ext4/Makefile

Which one of these four match patterh "Makefile*", which is "the first letter is 'M', the second letter is 'a', ....,, the eighth letter is 'e', and anything else can follow to the end"? Yes, only the first one.

Which one of these four match pattern "*Makefile", then? "Anything can appear as leading substring, but then 'M', 'a', 'k', ..., and finally 'e' must appear at the end"?

Note that these "start from the paths in the index that match the pathspec patterns" have nothing to do with "recursive". It happens way before we decide to go recursive (or not).

We are not going down recursively from the paths in the index that are matched by pathspec patterns with the above two "git rm" requests (because there is no "-r" there), but even if we were, because these three Makefile files are not directories, there is nothing to remove recursively underneath them.