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.
