26

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?

Adam Dymitruk
  • 124,556
  • 26
  • 146
  • 141

2 Answers2

21

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.

Adam Dymitruk
  • 124,556
  • 26
  • 146
  • 141
  • What about parallel commits with non-overlapping subsets (like, one commit commits one subtree and the second one commits the sibling)? I fear it can as well end with one of the commits set as HEAD and second one left dangling in unnamed branch :-/ –  Nov 19 '12 at 18:08
  • there's no problem there. Only one will win. Subsequent fetch from the one that got the short end of the deal will reveal the need to merge or rebase. – Adam Dymitruk Nov 19 '12 at 19:39
  • 1
    You should handle the case where there is a lock on the repo (.git/index.lock). Git does use this file to make sure the index does not get corrupted. – jeremy Nov 19 '12 at 19:42
  • 1
    @jeremy: So if I want serialize (non-overlapping, so it makes sense) commits, I just lock on `.git/index.lock` and I am done? Or it is on safer side to have lock on my own on the commits (push does not need the lock, as @AdamDymitriuk answered)? –  Nov 19 '12 at 20:13
  • 1
    No, the .git/index.lock is automatic and shouldn't be touched by an end-user unless there was a crash. If you are running multiple commits and pushes and encounter the index.lock error from Git, you should do something like 'git pull' and reattempt the action you were trying. – jeremy Nov 19 '12 at 20:20
3

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.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250