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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, 7 Oct 2017, Paul Smith wrote:

> On Sat, 2017-10-07 at 15:43 -0400, Robert P. J. Day wrote:
> >   it's been a long week, so take this in the spirit in which it is
> > intended ... i think the "git rm" command and its man page should be
> > printed out, run through a paper shredder, then set on fire. i can't
> > remember the last time i saw such a thoroughly badly-designed,
> > badly-documented and non-intuitive utility.
>
> "git rm" works the same way that the UNIX rm command has worked, for
> 40+ years now.  Very simple, very well designed, and very intuitive
> (IMO).
>
> The major difference is the ability to handle globbing patterns,
> which UNIX rm doesn't do.  Maybe the way this is implemented is a
> little confusing, although I just read the man page and it seemed
> pretty clear to me.

  um, wrong.

> If you don't use glob patterns (or more specifically if you let the
> shell handle glob patterns, which is how I always do it) then there
> is really nothing bizarre about "git rm".  Maybe you could be more
> precise in your criticism.

  ok, fine, let me explain why this command is a nightmarish
monstrosity. as i now understand, if i use an escaped wildcard
pattern, "git rm" will *automatically* (with no further guidance from
me, and no warning), operate recursively. so if, in the kernel source
tree, i ran:

  $ git rm \*.c

i would end up removing *all* 25,569 "*.c" files in the kernel source
repository.

  however, let's say i wanted to remove, recursively, all files with a
*precise* (non-globbed) name, such as "Makefile". so i, naively, run:

  $ git rm Makefile

guess what ... the lack of globbing means i remove only the single
Makefile at the top of the working directory.

  if that isn't an example of ridiculous, non-intuitive behaviour, i
don't know what is.

rday

-- 

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

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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux