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

[Junio C Hamano <gitster@pobox.com>]

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

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