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

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.