On Thursday 23 March 2006 01:24, Junio C Hamano wrote yet: > Radoslaw Szkodzinski <astralstorm@xxxxx> 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:
pgpSeRUeQJbhi.pgp
Description: PGP signature