fatal: Unable to create '/path/to/repo/.git/index.lock': File exists.

[shah-aditya]

I am using v 1.92.0.0 and Windows 10. I (and many of my colleagues) am constantly getting this error message when I try to do common operations like Pull, Checkout branch, Stage changes, Push, etc.

fatal: Unable to create 'path/to/repo/.git/index.lock': File exists.

Another git process seems to be running in this repository, e.g. an editor opened by 'git commit'. Please make sure all processes are terminated then try again. If it still fails, a git process may have crashed in this repository earlier: remove the file manually to continue.

When I check that folder location I do not see a file named "index.lock". I don't know how to fix this - my current workaround is to try again after 2-3 min and see if it works. Otherwise wait and try again. Our repo uses LFS, submodules and would be considered as a "large repo".

I found a similar issue in the Mac Fork issue tracker (https://github.com/fork-dev/Tracker/issues/1633). Thank you!

[DanPristupov]

Does the busy indicator on the status control spin? If it does, then it's probably blocked by git status.

[shah-aditya]

Yes the busy indicator keeps spinning and I don't know how to get it to stop... I've turned off the "Fetch remotes automatically" option.

[shah-aditya]

I tried fsmonitor (based on this https://github.blog/2022-06-29-improve-git-monorepo-performance-with-a-file-system-monitor/) but it does not seem to make it better. Maybe I am not implementing it correctly.

[DanPristupov]

Yes the busy indicator keeps spinning and I don't know how to get it to stop...

It will stop when git status stops.

Let's measure how long git status takes. Open Repository -> Benchmark and post the report here.

[shah-aditya]

Measuring system latency Measurements (s): 0.231, 0.223, 0.225, 0.228, 0.227, 0.226, 0.222 Avg: 0.226s

Reading changed files Measurements (s): 17.761, 16.788, 16.882, 16.730, 17.751, 16.779, 15.785 Avg: 16.986s

Reading branches and tags Measurements (s): 0.264, 0.252, 0.260, 0.244, 0.258, 0.248, 0.243 Avg: 0.252s

Reading commits Measurements (s): 0.342, 0.335, 0.329, 0.332, 0.335, 0.340, 0.329 Avg: 0.334s

Total time: 17.798s Avg test time: 4.450s Score = 10 / 4.450 = 2.2

0.226 16.986 0.252 0.334 2.2

[DanPristupov]

Reading changed files
Measurements (s): 17.761*, 16.788, 16.882, 16.730, 17.751, 16.779, 15.785*
Avg: 16.986s

Well, this is the worst result I've ever seen. It takes git ~17 seconds to read list of changed files. There isn't much Fork can do to improve that

What you can do though:

1. Open command line and run git gc, then run benchmark again.
2. Enable fs-monitor git config --local core.fsmonitor true. Run git config --local core.fsmonitor to check the current value.

[shah-aditya]

After running git gc and re-running benchmark:

Measuring system latency Measurements (s): 0.252, 0.239, 0.249, 0.244, 0.232, 0.228, 0.224 Avg: 0.238s

Reading changed files Measurements (s): 17.996, 14.207, 15.130, 16.023, 14.951, 16.939, 13.020 Avg: 15.450s

Reading branches and tags Measurements (s): 0.248, 0.237, 0.231, 0.231, 0.232, 0.233, 0.229 Avg: 0.233s

Reading commits Measurements (s): 0.382, 0.349, 0.364, 0.352, 0.354, 0.374, 0.344 Avg: 0.359s

Total time: 16.280s Avg test time: 4.070s Score = 10 / 4.070 = 2.5

0.238 15.450 0.233 0.359 2.5

After enabling fs-monitor and running benchmark again:

Measuring system latency Measurements (s): 0.247, 0.206, 0.208, 0.207, 0.225, 0.211, 0.204 Avg: 0.211s

Reading changed files Measurements (s): 18.911, 14.912, 14.975, 15.832, 16.872, 15.820, 12.846 Avg: 15.682s

Reading branches and tags Measurements (s): 0.236, 0.235, 0.218, 0.225, 0.212, 0.211, 0.211 Avg: 0.220s

Reading commits Measurements (s): 0.335, 0.330, 0.307, 0.325, 0.313, 0.311, 0.303 Avg: 0.317s

Total time: 16.431s Avg test time: 4.108s Score = 10 / 4.108 = 2.4

0.211 15.682 0.220 0.317 2.4

[DanPristupov]

Not such a big improvement...

1. How large is your repository (in GB)? Does it contain binary files?
2. Do you have an antivirus? Ensure that the source code directory is added to the white list.
3. Do you have an SSD or HDD?

[shah-aditya]

1. I used git-sizer (from https://github.blog/2018-03-05-measuring-the-many-sizes-of-a-git-repository/). Yes, it has a lot of binary files:

Processing blobs: 300310 Processing trees: 206011 Processing commits: 4053 Matching commits to trees: 4053 Processing annotated tags: 22 Processing references: 48	Name	Value	Level of concern
Overall repository size
* Blobs
* Total size	177 GiB	***
Biggest objects
* Trees
* Maximum entries [1]	2.68 k	**
* Blobs
* Maximum size [2]	237 MiB	****
Biggest checkouts
* Number of directories [3]	2.37 k	*
* Maximum path depth [4]	12	*
* Maximum path length [5]	244 B	**
* Total size of files [4]	2.01 GiB	**

2. I don't think I have antivirus
3. I have a SSD.

[DanPristupov]

Can you show output of the following command time git status --porcelain --untracked-files=no > /dev/null? it will run git-status, but without untracked files, which is usually faster.

Otherwise I don't se any way how to improve the performance.

[shah-aditya]

time git status --porcelain --untracked-files=no > /dev/null

real 0m12.370s user 0m0.031s sys 0m0.046s

[DanPristupov]

It's not a big improvement, but you can turn on Hide untracked files which will make status refresh slightly faster by not showing new files.

[shah-aditya]

After changing the setting and re-running the benchmark:

Measuring system latency Measurements (s): 0.237, 0.213, 0.213, 0.224, 0.234, 0.206, 0.206 Avg: 0.218s

Reading changed files Measurements (s): 17.120, 15.388, 13.184, 13.908, 15.183, 15.992, 13.162 Avg: 14.731s

Reading branches and tags Measurements (s): 0.252, 0.247, 0.239, 0.242, 0.241, 0.249, 0.239 Avg: 0.244s

Reading commits Measurements (s): 0.372, 0.352, 0.364, 0.353, 0.355, 0.368, 0.342 Avg: 0.358s

Total time: 15.551s Avg test time: 3.888s Score = 10 / 3.888 = 2.6

0.218 14.731 0.244 0.358 2.6

Slight benefit of ~1 sec. I guess I know what the root cause is now... thanks!

[DanPristupov]

I checked the source code, benchmark doesn't use Hide untracked files setting, so the score must be the same, however the real update time should be faster.

So, let me summarize:

1. Enable 'hide untracked files'
2. Wait until busy indicator disappear before making checkout or pull.

[shah-aditya]

Some follow-up questions:

• What would you classify my repo as? It is a large, very large, normal sized repo?
• If I ask a colleague to run the benchmark on the same repo their time is much smaller (2.5 seconds compared to 15 seconds for git-status). I have an Intel i7-6820 compared to Intel i7-11850. Is the time difference just from the processor, or is it a local setting on my computer?

[DanPristupov]

What would you classify my repo as? It is a large, very large, normal sized repo?

Generally speaking, binary files make git performance worse. However, 2GB working directory (Total size of files [4]) is not that big.

If I ask a colleague to run the benchmark on the same repo their time is much smaller (2.5 seconds compared to 15 seconds for git-status). ... Is the time difference just from the processor, or is it a local setting on my computer?

This is a very interesting observation. I think we can make a simple test. Try to make a fresh copy (clone) of the repository to some other folder. Is it faster?

[DanPristupov]

I think git status should do the following:

1. read each file from the working directory
2. perform a diff to the version in the repository

So performance should depend on SSD (1) and CPU (2).

According to comparison (https://cpu.userbenchmark.com/Compare/Intel-Core-i7-6820HQ-vs-Intel-Core-i7-11850H/m43500vsm1557007) Intel i7-11850 is 48% faster (?).

[shah-aditya]

This is a very interesting observation. I think we can make a simple test. Try to make a fresh copy (clone) of the repository to some other folder. Is it faster?

On a fresh clone:

• First time running Performance Benchmark
• After running git gc
• After turning on fs-monitor

Overall ~0.5 sec improvement in git status time comparing the fresh clone with the previous clone.

[DanPristupov]

I guess, it's CPU then.