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

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

On Mon, 9 Oct 2017, Jeff King wrote:

> On Sun, Oct 08, 2017 at 04:42:27PM -0400, Theodore Ts'o wrote:
>
> > On Sun, Oct 08, 2017 at 03:44:14PM -0400, Robert P. J. Day wrote:
> > > >
> > > >     find <find args> | xargs git rm
> > > >
> > > > myself.
> > >
> > >   that's what i would have normally used until i learned about
> > > git's magical globbing capabilities, and i'm going to go back to
> > > using it, because git's magical globbing capabilities now scare
> > > me.
> >
> > Hmm, I wonder if the reason why git's magically globbing
> > capabilities even exist at all is for those poor benighted souls
> > on Windows, for which their shell (and associated utilities)
> > doesn't have advanced tools like "find" and "xargs"....
>
> One benefit of globbing with Git is that it restricts the matches
> only to tracked files. That matters a lot when you have a very broad
> glob (e.g., like you might use with "git grep") because it avoids
> looking at cruft like generated files (or even inside .git).

  ah, now *that* is a compelling rationale that justifies the
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?

rday

-- 

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

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