Is a local Git repository thread-safe?

Question

Is a local Git repository guaranteed to be free of race conditions if two users try to use the repository at the same time?

Assume two users on a Linux system running git commit at the same time, or that a user was applying a patch while another user was trying to checkout a branch, is Git's behavior well-defined in such cases?

Answer 1

Git uses locking and atomic renames to avoid data corruption issues within the .git directory. So it is, for example, possible to have a git gc going on while performing other operations, and no data will be lost, nor will the repository appear corrupt or missing objects at any point. It is still possible that certain concurrent operations (e.g., updating the index) may abort due to contention over a lock, though.

However, having said that, the working tree isn't guaranteed to be free of races. For example, there's no atomic way to replace a file with a directory, and git checkout doesn't attempt to be atomic as a consequence. Similarly, applying a patch during a checkout will probably result in data loss or unexpected failure.

If you need to have multiple programs working with the same repository, consider using a bare repository and something like libgit2 or one of its language-specific wrappers. That will make it much easier for you to create multiple branches and commits without needing to contend over a working tree.

If you need multiple human users to work with a repository, you should use multiple copies of the repository. Users will not enjoy sharing a working tree and you'll run into practical issues if two people are using one at once. In addition, Git's security model doesn't allow for a malicious user to share a repository other than over the transfer protocol; for example, hooks that are called automatically can execute arbitrary code. Even non-malicious users may want to have custom hooks or other configuration (e.g., .git/info/exclude) that makes sharing a repository undesirable.