Re: "git rm" seems to do recursive removal even without "-r"
- Date: Sat, 7 Oct 2017 15:12:01 -0400 (EDT)
- From: "Robert P. J. Day" <rpjday@xxxxxxxxxxxxxx>
- Subject: Re: "git rm" seems to do recursive removal even without "-r"
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
> # With bash performing file globbing
> $ git rm -n Documentation/*.txt | wc -l
> # With git performing file globbing
> $ git rm -n Documentation/\*.txt | wc -l
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/
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?
Robert P. J. Day Ottawa, Ontario, CANADA