list mirror (unofficial, one of many)
 help / color / mirror / Atom feed
From: Paul Smith <>
To: "Robert P. J. Day" <>
Cc: Git Mailing list <>
Subject: Re: "git rm" seems to do recursive removal even without "-r"
Date: Sun, 08 Oct 2017 10:32:40 -0400
Message-ID: <> (raw)
In-Reply-To: <alpine.LFD.2.21.1710071749240.16818@localhost.localdomain>

On Sat, 2017-10-07 at 17:55 -0400, Robert P. J. Day wrote:
> 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.

I don't know what part of my comment here you consider "wrong".  I've
re-read it and I believe everything I said is correct.

> > 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

Yes, this is what I said: "IF YOU DON'T USE GLOB PATTERNS (or more
specifically if you let the shell handle glob patterns ...) then there
is nothing bizarre about "git rm"" (emphasis added).

In this example you ARE sending glob patterns to Git, because you're
escaping them from the shell.  Hence, you might consider the behavior
bizarre, at least until you grok it fully.

If you want to avoid this, simply use normal shell globbing and don't
ask Git to do the globbing for you.  Then it behaves exactly as normal
UNIX rm, including with the '-r' option, and is very simple.

> so if i wanted git to remove, say, all files named "Makefile*" from
> everywhere in the linux kernel source tree, the (dry run) command
> would be:
>   $ git rm -n Makefile\*
> is that it? let's try that:
>   $ git rm -n Makefile\*
>   rm 'Makefile'
>   $
> oops.

Globbing in "git rm" matches on the FULL PATH, not just the file name. 
So, if you have a list of Makefiles in your repository like:


Then 'Makefile*' only matches the first one, since 'Makefile*' doesn't
match 'foo/Makefile' or 'bar/Makefile'.

If you you worry that '*Makefile' will match things you don't want to
match, you'll have to use:

  git rm -n Makefile '*/Makefile'

Personally I don't use Git's magical globbing capabilities, and use "git
rm" as if it were UNIX rm.  So in your request above I'd use:

   git rm $(find . -name Makefile)

which I find simpler.

  parent reply	other threads:[~2017-10-08 14:32 UTC|newest]

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
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 [this message]
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 publicly 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:

  List information:

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

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link list mirror (unofficial, one of many)

This inbox may be cloned and mirrored by anyone:

	git clone --mirror
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 git git/ \
	public-inbox-index git

Example config snippet for mirrors.
Newsgroups are available over NNTP:
 note: .onion URLs require Tor:

code repositories for the project(s) associated with this inbox:

AGPL code for this site: git clone