CODEWITHSUNDEEP
gitversion-controllockingrace-condition
user1046334
user1046334

Reputation:

Is it safe if more git commands are run on the same repo in parallel?

I am interested if it is safe to run things like git push and git commit in parallel (for example in cron jobs, jenkins jobs etc.). Is there some locking mechanism built-in in git so these operations are serialized or this can corrupt the repository?

Upvotes: 26

Views: 4294

Answers (2)

VonC
VonC

Reputation: 1324937

In theory, there could be a rare case of race condition for the git commit part, where the HEAD file is not available.
That was silent before Git 2.15.x/2.16 (Q1 2018). It won't be silent anymore.

See commit c26de08 (20 Oct 2017) by Andrey Okoshkin (``).
(Merged by Junio C Hamano -- gitster -- in commit 4a1638c, 06 Nov 2017)

commit: check result of resolve_ref_unsafe

Add check of the resolved HEAD reference while printing of a commit summary.
resolve_ref_unsafe() may return NULL pointer if underlying calls of lstat() or open() fail in files_read_raw_ref().
Such situation can be caused by race: file becomes inaccessible to this moment.

The message becomes:

if (!head)
    die_errno(_("unable to resolve HEAD after creating commit"));

With Git 2.36 (Q2 2022), the message content changes:

See commit ce14de0, commit 09444e7 (26 Jan 2022) by Ævar Arnfjörð Bjarmason (avar).
(Merged by Junio C Hamano -- gitster -- in commit 03bdcfc, 11 Feb 2022)

sequencer: don't use die_errno() on refs_resolve_ref_unsafe() failure

Signed-off-by: Ævar Arnfjörð Bjarmason

Change code that was faithfully migrated to the new "resolve_errno" API in ed90f04 ("refs API: make resolve_ref_unsafe() not set errno", 2021-10-16, Git v2.35.0-rc0 -- merge listed in batch #1) to stop caring about the errno at all.

When we fail to resolve "HEAD" after the sequencer runs it doesn't really help to say what the "errno" value is, since the fake backend errno may or may not reflect anything real about the state of the ".git/HEAD".
With the upcoming reftable backend this fakery will become even more pronounced.

So let's just die() instead of die_errno() here.
This will also help simplify the refs_resolve_ref_unsafe() API.
This was the only user of it that wasn't ignoring the "failure_errno" output parameter.

Upvotes: 3

Adam Dymitruk
Adam Dymitruk

Reputation: 129584

Yes. Git works by writing references in a manner that allows for this. If you are doing a commit at the same time as a push, push will only go from the references down to the objects they contain. If the commit finishes and updates the branch reference on time, it will get pushed. If it doesn't, the old reference will be pushed. You won't get "half a commit" pushed up.

All files are written in a manner that implicitly preserves referential integrity for any pointers. The last file written will be the reference that already has all it's dependencies there.

Upvotes: 21

Related Questions