26

I am using git for source control on a repository. Recently it has begun warning me about how long it takes to enumerate untracked files when using git status:

$ git status
On branch my_branch
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   My_Project/my_source.c


It took 3.24 seconds to enumerate untracked files. 'status -uno'
may speed it up, but you have to be careful not to forget to add
new files yourself (see 'git help status').
no changes added to commit (use "git add" and/or "git commit -a")

However, there are no untracked files in this repository – I checked with git status -uall. Some other possibly relevant information:

  • I've noted that this warning only appears when git status does indeed take a few seconds to run.
  • My repository is 130.6 MB at the moment.
  • My build products are all out-of-tree.

Why does git take so long to enumerate untracked files that do not exist?

Here are some relevant other questions:

Community
  • 1
  • 1
ravron
  • 11,014
  • 2
  • 39
  • 66
  • 6
    "Untracked files" includes files that are ignored by `.gitignore` and friends. The size of your repository doesn't really matter, since `git status` only `lstat()`s your files. What matters is how many files there are, how deeply nested your directory tree is and how fast your filesystem is. – Sven Marnach Jan 26 '15 at 19:09
  • 1
    If you have lots of build artifacts in your tree, you might consider using out-of-tree builds to speed things up. – Sven Marnach Jan 26 '15 at 19:10
  • @SvenMarnach Interesting. My builds are already out-of-tree – I've edited my question to reflect this. My project is big, but not crazy – the vast majority of sources are one level deep, and there are 334 such files at last count. – ravron Jan 26 '15 at 19:20
  • This indeed doesn't sound big at all. What filesystem are you on? – Sven Marnach Jan 26 '15 at 19:21
  • HFS+ (specifically, HFSJ) – that is, modern OS X. I'm going to run some disk checks in a few minutes – it might be something wholly external to git. – ravron Jan 26 '15 at 19:25
  • No idea then. It *should* be faster than that. Try and see whether `find | wc -l` takes an unexpectedly long time, or prints an unexpectedly big number of files. (Note: that will include your `.git` directory.) – Sven Marnach Jan 26 '15 at 19:29
  • Following up: hitting disk continued to get slower throughout my system. I finally replaced my hard drive about a month ago, and I have not seen this warning since. – ravron Sep 29 '15 at 22:13
  • can you try `git rm --cached stuff.txt`? – seoyoochan Dec 24 '15 at 05:49
  • As mentioned, I've replaced my drive and since not encountered this issue. – ravron Dec 24 '15 at 23:26

3 Answers3

9

First, I want to acknowledge Sven Marnach's comments above that basically gave me this solution.

Problem: I had this problem too, but my HD(s) is/are fine. It takes 3-5 seconds to do a "git status" on a SSD drive and 4-8 seconds on a magnetic one. It's a lot faster after I've done it a few times. I also see this error about taking so long to enumerate untracked files but I have no changes to commit.

Quick Solution: Delete whatever files are being hidden by your .gitignore files.

Better Solution: Stop building in the same directory that is in source control.

Why: Git still has to go through all the non-tracked files, see if there any new ones and then cross-reference them against the entries in .gitignore. This error is not saying that you have files that need to be checked in, rather that it's taking a really long time these days to figure out if there's a file that needs to be checked in.

On a clean checkout where there are no files to be hidden by git ignore and an SSD drive, running "git status" takes 0.8 seconds.

One last note: This is a really old project and we have a really large .gitignore file. I suspect that reducing 100 entries down to a single directory would help too, but unfortunately we have a few files in each of these output directories that are checked in.

Ryan Shillington
  • 23,006
  • 14
  • 93
  • 108
  • 1
    _"Stop building in the same directory that is in source control."_ You'll have to tell that to the Go developers. The `vendors` directory is rarely less than a few thousand files in my environment... – Alexis Wilke Aug 03 '22 at 16:21
5

My solution was to remove full file paths in .gitignore and ignore directories instead where possible.

Just to note my gitignore was 15000 lines long.

minlare
  • 2,454
  • 25
  • 46
  • Solved my problem, because I accidently overlooked directory as the files contained therein were already catched by patterns in `.gitignore` - but as the directory itself was missing in `.gitignore`, git was slooooow because it remains checking the whole content. – Thomas Aug 08 '23 at 09:14
4

Just for clarifying the solution gave by the author in the latest comment:

I've replaced my drive and since not encountered this issue.

The problem was not in git itself but instead the problem was in the computer Hardware.
Once the HD was replaced - issue resolved.

CodeWizard
  • 128,036
  • 21
  • 144
  • 167