Wildcards with git rm

Wildcards with git rm

[RPS]

git rm doesn't seem to be very useful without the use of shell 
wildcards, especially with the use of a .gitignore file. If a .gitignore 
file is used, the git rm command does not consider the .gitignore file, 
and errs out when an ignored file is present.

In my opinion, git rm should take .gitignore into consideration and 
suppress errors for those files along with all other commands in order 
to target valid repository files in the current version. Also, git rm 
should either remove the ignored files and other present  files in the 
working copy to act like a shell rm command along with existing version 
controlled objects from the version, or skip ignored working copy files 
and err out on files not accounted for in the current version.

Have there been any design considerations on these things?

Jim Lutz


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: Wildcards with git rm

[Junio C Hamano]

RPS <jim@resplendentwebservices.com> writes:

> git rm doesn't seem to be very useful without the use of shell
> wildcards, especially with the use of a .gitignore file. If a
> .gitignore file is used, the git rm command does not consider the
> .gitignore file, and errs out when an ignored file is present.

Do you mean

	$ git rm COPY*

would complain about COPYING~ on your filesystem, which would match
the pattern "*~" you have in your .gitignore file, after editing the
tracked COPYING file?

If so, you may choose to tell your shell _not_ to expand wildcards,
as it does not know what is ignored, by doing

	$ git rm COPY\*

instead.  That would allow "git rm" to expand wildcards _with_ the
knowledge of what is and is not ignored.  The shell does not know
(probably you could teach if you wanted to, but it does not want to
know) and care about .gitignore files when it does its wildcard
expansion.