{"thread":{"id":"47053","subject":"Wildcards with git rm","startedAt":"2017-10-28T11:54:33Z","lastAt":"2017-10-30T00:58:10Z","messageCount":2,"participants":["RPS","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"331217","messageId":"cbb7340e-aa8c-1980-41eb-95cd965d4037@resplendentwebservices.com","threadId":"47053","inReplyTo":null,"subject":"Wildcards with git rm","fromName":"RPS","fromEmail":"jim@resplendentwebservices.com","sentAt":"2017-10-28T11:38:44Z","receivedAt":"2017-10-28T11:54:33Z","isPatch":false,"sender":{"key":"jim@resplendentwebservices.com","avatar":null},"body":"git rm doesn't seem to be very useful without the use of shell \nwildcards, especially with the use of a .gitignore file. If a .gitignore \nfile is used, the git rm command does not consider the .gitignore file, \nand errs out when an ignored file is present.\n\nIn my opinion, git rm should take .gitignore into consideration and \nsuppress errors for those files along with all other commands in order \nto target valid repository files in the current version. Also, git rm \nshould either remove the ignored files and other present  files in the \nworking copy to act like a shell rm command along with existing version \ncontrolled objects from the version, or skip ignored working copy files \nand err out on files not accounted for in the current version.\n\nHave there been any design considerations on these things?\n\nJim Lutz\n\n\n---\nThis email has been checked for viruses by Avast antivirus software.\nhttps://www.avast.com/antivirus\n\n"},{"id":"331302","messageId":"xmqqk1zd8nac.fsf@gitster.mtv.corp.google.com","threadId":"47053","inReplyTo":"cbb7340e-aa8c-1980-41eb-95cd965d4037@resplendentwebservices.com","subject":"Re: Wildcards with git rm","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-10-30T00:58:03Z","receivedAt":"2017-10-30T00:58:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"RPS <jim@resplendentwebservices.com> writes:\n\n> git rm doesn't seem to be very useful without the use of shell\n> wildcards, especially with the use of a .gitignore file. If a\n> .gitignore file is used, the git rm command does not consider the\n> .gitignore file, and errs out when an ignored file is present.\n\nDo you mean\n\n\t$ git rm COPY*\n\nwould complain about COPYING~ on your filesystem, which would match\nthe pattern \"*~\" you have in your .gitignore file, after editing the\ntracked COPYING file?\n\nIf so, you may choose to tell your shell _not_ to expand wildcards,\nas it does not know what is ignored, by doing\n\n\t$ git rm COPY\\*\n\ninstead.  That would allow \"git rm\" to expand wildcards _with_ the\nknowledge of what is and is not ignored.  The shell does not know\n(probably you could teach if you wanted to, but it does not want to\nknow) and care about .gitignore files when it does its wildcard\nexpansion.\n"}]}