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
-
Why does one user need multiple instances of Eclipse using the same repo? – Schwern May 25 '17 at 18:35
2 Answers
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.

- 153,029
- 25
- 195
- 336
-
will the .git/index.lock be created in check out operation?Problem is One instance is trying to check out a specific commit of a file ,at the same time if another instance trying to check out a different commit of that same file.it results in confusion.Is there any solution for this scenario. – Renganathan Selvaraju May 25 '17 at 08:57
-
@RenganathanSelvaraju In that case what you want is [`git-worktree`](https://git-scm.com/docs/git-worktree) to create multiple worktrees (ie. checkouts) sharing single repository. Each instance would use its own worktree. Or you can just have multiple clones. – Schwern May 25 '17 at 18:34
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 correctlySigned-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 tologs/HEAD
(HEAD
is specific to the worktree, and therefore so is its reflog). However, the wrong path is returned forlogs/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 fromgit_path("logs/HEAD")
by appending the.lock
suffix.However, Git GUI just learned to use
--git-path
instead of appending relative paths to whatgit 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 forlogs/HEAD.lock
, let's be safe rather than sorry.Side note: Git GUI
_does
_ ask forindex.lock
, but that is already resolved correctly, due toupdate_common_dir()
preferring to leave unknown paths in the (worktree-specific) git directory.