Re: Question about possible git races

From: Radoslaw Szkodzinski <astralstorm@o2.pl>
Date: Mar 23, 2006, 01:22 UTC
Message-ID: <200603230222.38978.astralstorm@o2.pl>
In-Reply-To: <7vacbi6m91.fsf@assigned-by-dhcp.cox.net>

On Thursday 23 March 2006 01:24, Junio C Hamano wrote yet:

Show 19 quoted lines

> Radoslaw Szkodzinski <astralstorm@o2.pl> writes:
> > - push vs pull
> >
> > - push vs push
> >
> > - fetch vs fetch
>
> About push vs push, with "really bare git", I take it that you
> mean two send-pack from remote sites running two receive-pack
> simultaneously.
>
> There is an explicit race avoidance between the receive-pack
> processes.  When a ref (either branch head or a tag) is updated,
> it does:
>
>  - read the current value from the ref.
>  - do its work.
>  - lock to prevent others to create the temporary file for
>    updating the ref.

Show 7 quoted lines

>  - create the temporary file for the ref and write the new value.
>  - check if the ref's value has not changed from what it
>    initially read;
>  - rename the temporary file to the ref to unlock.
>
> Read receive-pack.c::update() for exact details if you are
> interested.

So there is locking I've missed while reading through the source. Guess all the coffee doesn't help.

There is a lock, so the other git-receive-pack for given ref will fail. Does that also work for git-local-fetch with -l option?

Looks good though that I can fetch to another ref.

Show 5 quoted lines

>
> > I'm meaning really bare git there, w/o bash+perl scripts.
>
> The question does not make any sense for other cases, because
> branch update by fetch and pull are all scripts based.

I should have known better than to use vague words. For me fetch = git-*-fetch. Which in turn calls git-receive-pack.

Thank you for the precise answer.

-- 
GPG Key id:  0xD1F10BA2
Fingerprint: 96E2 304A B9C4 949A 10A0  9105 9543 0453 D1F1 0BA2

AstralStorm