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:

Improve this question
9
  • 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. Commented Jan 26, 2015 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. Commented Jan 26, 2015 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. Commented Jan 26, 2015 at 19:20
  • This indeed doesn't sound big at all. What filesystem are you on? Commented Jan 26, 2015 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. Commented Jan 26, 2015 at 19:25

3 Answers 3

Reset to default
10

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.

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

"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...
6

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.

Improve this answer

Comments

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.

Improve this answer

1 Comment

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.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.