From: Paul Smith <email@example.com> To: "Robert P. J. Day" <firstname.lastname@example.org> Cc: Git Mailing list <email@example.com> Subject: Re: "git rm" seems to do recursive removal even without "-r" Date: Sun, 08 Oct 2017 10:32:40 -0400 Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <alpine.LFD.email@example.com> 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: Makefile foo/Makefile bar/Makefile 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.
next prev 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 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 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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /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
firstname.lastname@example.org list mirror (unofficial, 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/ AGPL code for this site: git clone https://public-inbox.org/ public-inbox