Re: git rm VERY slow for directories with many files.

"brian m. carlson" writes: > On Sun, Oct 29, 2017 at 09:51:55AM +0900, Junio C Hamano wrote: >> "brian m. carlson" writes: >> > First, make sure your working directory is clean with no changes. Then, >> > remove the directory (by

Re: git rm VERY slow for directories with many files.

On Sun, Oct 29, 2017 at 09:51:55AM +0900, Junio C Hamano wrote: > "brian m. carlson" writes: > > First, make sure your working directory is clean with no changes. Then, > > remove the directory (by hand) or move it somewhere else. Then, run > > "git add -u". > > >

Re: git rm VERY slow for directories with many files.

Junio C Hamano writes: > I wonder how fast "git diff-index --cached -r HEAD --", with the > same pathspec used for the problematic "git rm", runs in this same > 50,000 path project. > > If it runs in a reasonable time, one easy way out may be to revamp > the codepath to call

Re: git rm VERY slow for directories with many files.

"brian m. carlson" writes: >> Looking at an optimized profile, all the time seems to be spent in >> “get_tree_entry” — I assume there is some huge object representing the >> directory which is being re-expanded for each file? > > Yes, there's a tree object that

Re: git rm VERY slow for directories with many files.

On Sat, Oct 28, 2017 at 05:02:02PM +, Christopher Jefferson wrote: > I stupidly added a directory with many files ( ~450,000 ) to git, and want to > delete them — later I plan to rebase/squash various commits to remove the > files from the history altogether. > > However, ‘git rm’ is VERY

git rm VERY slow for directories with many files.

I stupidly added a directory with many files ( ~450,000 ) to git, and want to delete them — later I plan to rebase/squash various commits to remove the files from the history altogether. However, ‘git rm’ is VERY slow. For example, in a directory with 10,000 files (on a Mac), git v2.14.2 Git