lock git repository if it is already in use

问题

I am having a local repository ,Which has sub module repository also.If i try to access the repository from two different instance of eclipse third party tool.Will git prevent the access for second third party tool if that eclipse repository is being by used by first third eclipse party tool? if git does not restrict the second third party tool how to do that restriction.User is same for all third party tool

回答1:

Yes, Git has protections against multiple processes writing to the same repository at the same time.

It uses lockfiles. .git/index.lock locks the index (aka the staging area) during git add. .git/HEAD.lock locks HEAD during git commit. .git/refs/heads/master will lock the master branch when it's being moved, and so on. Other processes will wait until the piece of the repository they need is available.

Many processes can safely read at the same time, so as many processes can be running git log or git diff simultaneously.

Most Git commands are so fast you should never notice.

回答2:

With Git 2.25 (Q1 2020), "git rev-parse --git-path HEAD.lock" (one of the way to control concurrent acces) did not give the right path when run in a secondary worktree.

See commit 76a53d6, commit 3ce4721 (28 Oct 2019) by Johannes Schindelin (dscho).
^{(Merged by Junio C Hamano -- gitster -- in commit a2b0451, 01 Dec 2019)}

git_path(): handle .lock files correctly

^{Signed-off-by: Johannes Schindelin}

Ever since worktrees were introduced (Git 2.5, July 2015) , the git_path() function _really_ needed to be called e.g. to get at the path to logs/HEAD (HEAD is specific to the worktree, and therefore so is its reflog). However, the wrong path is returned for logs/HEAD.lock.

This does not matter as long as the Git executable is doing the asking, as the path for that logs/HEAD.lock file is constructed from git_path("logs/HEAD") by appending the .lock suffix.

However, Git GUI just learned to use --git-path instead of appending relative paths to what git rev-parse --git-dir returns (and as a consequence not only using the correct hooks directory, but also using the correct paths in worktrees other than the main one). While it does not seem as if Git GUI in particular is asking for logs/HEAD.lock, let's be safe rather than sorry.

Side note: Git GUI _does_ ask for index.lock, but that is already resolved correctly, due to update_common_dir() preferring to leave unknown paths in the (worktree-specific) git directory.