Git rm several files?

Question

How do I easily remove several files without manually typing the full paths of all of them to git rm? I have plenty of modified files I\'d like to keep so remov

Answer 1

On Windows 10, using Git Bash, from the .gitignore location in your file structure.

git rm -r --cached some_directory/

I just used this to ignore a whole directory, recursively. This is what is in my .gitignore file for this:

# Use .gitignore to ignore a directory and its contents #
/some_directory/ 

Answer 2

You simply use

find . -name '*.DS_Store' | xargs git rm

to remove many files match the wildcards.

Answer 3

Just delete them using any other method (Explorer, whatever), then run git add -A. As to reverting several files, you can also checkout a directory.

Answer 4

On POSIX systems, you can create a shell glob that will match all desired files, you can simply pass that to git rm and git checkout --. On Windows, cmd.exe and PowerShell do not include globbing and farm that out to the applications (git doesn't do it for files, from what I've read). You would need to use a Windows command or script to prepare a file list and pipe it to your git commands appropriately to get a similar effect.

Any strategy that you would use to pass a list of files to a shell command will work for git commands that accept file paths.

Answer 5

Or you can just write down the names of all the files in another file, say filesToRemove.txt

That is a good approach with Git 2.26 (Q2 2020), since "git rm" and "git stash" learns the new "--pathspec-from-file" option.

So no more for i incat filesToRemove.txt; do git rm $i; done

A simple git rm --pathspec-from-file=filesToRemove.txt is enough.

See commit 8a98758, commit 8c3713c, commit 3f3d806, commit b229091, commit 0093abc, commit 2b7460d, commit 5f393dc (17 Feb 2020), and commit 6a7aca6 (16 Jan 2020) by Alexandr Miloslavskiy (SyntevoAlex).
^{(Merged by Junio C Hamano -- gitster -- in commit 9b7f726, 09 Mar 2020)}

rm: support the --pathspec-from-file option

^{Signed-off-by: Alexandr Miloslavskiy}

Decisions taken for simplicity:

It is not allowed to pass pathspec in both args and file.

Adjustments were needed for if (!argc) block:

This code actually means "pathspec is not present".
Previously, pathspec could only come from commandline arguments, so testing for argc was a valid way of testing for the presence of pathspec. But this is no longer true with --pathspec-from-file.

During the entire --pathspec-from-file story, I tried to keep its behavior very close to giving pathspec on commandline, so that switching from one to another doesn't involve any surprises.

However, throwing usage at user in the case of empty --pathspec-from-file would puzzle because there's nothing wrong with "usage" (that is, argc/argv array).

On the other hand, throwing usage in the old case also feels bad to me. While it's less of a puzzle, I (as user) never liked the experience of comparing my commandline to "usage", trying to spot a difference. Since it's already known what the error is, it feels a lot better to give that specific error to user.

Judging from commit 7612a1ef ("git-rm: honor -n flag" 2006-06-09, git v1.4.0), it doesn't seem that showing usage in this case was important (the patch was to avoid segfault), and it doesn't fit into how other commands react to empty pathspec (see for example git add with a custom message).

Therefore, I decided to show new error text in both cases.
In order to continue testing for error early, I moved parse_pathspec() higher. Now it happens before read_cache() / hold_locked_index() / setup_work_tree(), which shouldn't cause any issues.