git@vger.kernel.org mailing list mirror (one of many)
 help / Atom feed
From: "Robert P. J. Day" <rpjday@crashcourse.ca>
To: Junio C Hamano <gitster@pobox.com>
Cc: Paul Smith <paul@mad-scientist.net>, Git Mailing list <git@vger.kernel.org>
Subject: Re: "git rm" seems to do recursive removal even without "-r"
Date: Sun, 8 Oct 2017 07:56:20 -0400 (EDT)
Message-ID: <alpine.LFD.2.21.1710080736530.21897@localhost.localdomain> (raw)
In-Reply-To: <xmqqy3oms22q.fsf@gitster.mtv.corp.google.com>

On Sun, 8 Oct 2017, Junio C Hamano wrote:

> "Robert P. J. Day" <rpjday@crashcourse.ca> writes:
>
> > ... 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.
>
> Yes, as that is exactly what the command line asks Git to do.

  ok, i truly want to understand this, so let me dig through this
carefully. i can now see (from the man page and the recent
explanations) that "git rm" will accept *escaped* fileglobs to remove
and that, further, "File globbing matches across directory
boundaries." which is why, in the linux kernel source tree, if i run
one of:

  $ git rm \*.c
  $ git rm '*.c'

the "git rm" command will internally process the fileglob and apply it
across directory boundaries. and that's why, when i try a dry run, i
can see the effect it would have on the kernel source:

  $ git rm -n '*.c' | wc -l
  25569
  $

> If you said
>
>     $ git rm *.c
>
> then the shell expands the glob and all Git sees is that you want to
> remove a.c b.c d.c ...; if you said "git rm -r *.c", unless b.c is
> not a directory, these and only these files are removed.

  right, that's just regular shell fileglob processing, no surprise
there. (let's stick to just file removal for now.)

> >   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.
>
> Again, that is exactly what you asked Git to do.

  yes, now i get it -- a lack of fileglob arguments disallows
traversing directory boundaries, so one gets the "normal" behaviour.

>     $ git rm $(find . -name Makefile -print)
>
> would of course one way to remove all Makefiles.  If you let POSIX
> shell glob, i.e.
>
>     $ git rm */Makefile
>
> the asterisk would not expand nothing but a single level, so it may
> remove fs/Makefile, but not fs/ext4/Makefile (some shells allow
> "wildmatch" expansion so "git rm **/Makefile" may catch the latter
> with such a shell).

  sure, all regular shell fileglob processing.

> By letting Git see the glob, i.e.
>
>     $ git rm Makefile \*/Makefile
>
> you would let Git to go over the paths it knows/cares about to find
> ones that match the pathspec pattern and remove them (but not
> recursively, even if you had a directory whose name is Makefile; for
> that, you would use "-r").

  right ... i can now see that '*/Makefile' would pick up all
Makefiles *below* the current directory, so you need that initial
reference to 'Makefile' to catch the top one. this just seems ...
awkward.

  but as i asked in my earlier post, if i wanted to remove *all* files
with names of "Makefile*", why can't i use:

  $ git rm 'Makefile*'

just as i used:

  $ git rm '*.c'

are those not both acceptable fileglobs? why does the former clearly
only match the top-level Makefile, and refuse to cross directory
boundaries?

  $ git rm -n 'Makefile*'
  rm 'Makefile'
  $

rday

-- 

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

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

  parent reply index

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-07 18:39 Robert P. J. Day
2017-10-07 19:04 ` Todd Zullinger
2017-10-07 19:12   ` Robert P. J. Day
2017-10-07 19:29     ` Jeff King
2017-10-07 19:32       ` Robert P. J. Day
2017-10-07 19:38         ` Jeff King
2017-10-07 19:43           ` Robert P. J. Day
2017-10-07 21:05             ` Theodore Ts'o
2017-10-07 21:40               ` Robert P. J. Day
2017-10-07 21:44             ` Paul Smith
2017-10-07 21:55               ` Robert P. J. Day
2017-10-08  4:20                 ` Junio C Hamano
2017-10-08  9:07                   ` Robert P. J. Day
2017-10-08 11:37                     ` Kevin Daudt
2017-10-08 11:56                   ` Robert P. J. Day [this message]
2017-10-08 12:23                     ` Martin Ågren
2017-10-08 12:39                     ` René Scharfe
2017-10-08 12:45                       ` Robert P. J. Day
2017-10-10 11:52                     ` Heiko Voigt
2017-10-11  8:31                       ` Robert P. J. Day
2017-10-08 14:32                 ` Paul Smith
2017-10-08 18:40                   ` Theodore Ts'o
2017-10-08 19:44                     ` Robert P. J. Day
2017-10-08 20:42                       ` Theodore Ts'o
2017-10-09 17:52                         ` Jeff King
2017-10-10  8:36                           ` Robert P. J. Day
2017-10-10  8:58                             ` Junio C Hamano
2017-10-10 12:19                             ` Paul Smith
2017-10-10 19:44                               ` Robert P. J. Day

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.2.21.1710080736530.21897@localhost.localdomain \
    --to=rpjday@crashcourse.ca \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=paul@mad-scientist.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

git@vger.kernel.org mailing list mirror (one of many)

Archives are clonable:
	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.org/gmane.comp.version-control.git

 note: .onion URLs require Tor: https://www.torproject.org/
       or Tor2web: https://www.tor2web.org/

AGPL code for this site: git clone https://public-inbox.org/ public-inbox