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

["Robert P. J. Day" <rpjday@crashcourse.ca>]

On Sat, 7 Oct 2017, Todd Zullinger wrote:

> Robert P. J. Day wrote:
> >
> >  was just testing variations of "git rm", and man page claims:
> >
> >  -r     Allow recursive removal when a leading directory name is given.
> >
> > i tested this on the "pro git" book repo, which contains a top-level "book/"
> > directory, and quite a number of "*.asc" files in various subdirectories one
> > or more levels down. i ran:
> >
> >  $ git rm book/\*.asc
> >
> > and it certainly seemed to delete *all* "*.asc" files no matter where they
> > were under book/, even without the "-r" option.
> >
> >  am i misunderstanding something?
>
> By shell-escaping the *, you're letting git perform the file glob.  The
> DISCUSSION section of git-rm(1) says "File globbing matches across directory
> boundaries."
>
> # With bash performing file globbing
> $ git rm -n Documentation/*.txt | wc -l
> 199
>
> # With git performing file globbing
> $ git rm -n Documentation/\*.txt | wc -l
> 578

  ok, in that case, can you give me an example where "-r" makes a
difference, given that the man page refers to "a leading directory
name being given"? let's use as an example the linux kernel source,
where there are a *ton* of files named "Makefile" under the drivers/
directory.

  should there be a difference between:

  $ git rm drivers/Makefile
  $ git rm -r drivers/Makefile

clearly, i have a "leading directory name" in both examples above ...
what should happen differently?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================