What Git operations lock the database?

Question

Git has a variety of operations for reading/writing to their internal database. I've read that write operations are atomic in Git. However, for other operations like reads, what operations will lock the database?

Specifically, I am writing an application that will be concurrently calling "git blame" and I want to make sure this is something that I can multithread.

Answer 1

I didn’t check this in the source, but from knowing git’s internal structure, I would say that everything apart from git gc can be multithreaded.

Git is just a bunch of object files that reference each other, but are only allowed to reference in one direction (“the past”). Apart from branch heads, the contents of a git repository can not be modified (only extended) and git gc is the only operation that will delete stuff from a git repository.

That is why git needs absolute minimal locking, and also why you should be fine. Note that the index is excepted from all this – that will be frequently locked, but git blame HEAD and every command you would run on a bare repo do not use the index.

Answer 2

Minimal locking is indeed needed.

The only caveat is when running several git gc concurrently, as illustrated by commit ed7eda8 by Kyle J. McKay (mackyle) for Git 1.9/2.0 (Q1 2014), actually Git 1.8.5.3, released January 15th, 2014.

Since 64a99eb4 (git 1.8.5), git gc refuses to run without the --force option if another gc process on the same repository is already running.

However, if the repository is shared and user A runs git gc on the repository and while that gc is still running user B runs git gc on the same repository the gc process run by user A will not be noticed and the gc run by user B will go ahead and run.

The problem is that the kill(pid, 0) test fails with an EPERM error since user B is not allowed to signal processes owned by user A (unless user B is root).

Update the test to recognize an EPERM error as meaning the process exists and another gc should not be run (unless --force is given).

So unless you are in that scenario, you can call you other git commands concurrently without any issue.