Re: Question about possible git races

[Radoslaw Szkodzinski <astralstorm@o2.pl>]

[-- Attachment #1: Type: text/plain, Size: 1681 bytes --]

On Thursday 23 March 2006 01:24, Junio C Hamano wrote yet:
> 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.


>  - 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.

>
> > 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

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]