RE: Question re. git remote repository
- From
- David Lang <david@lang.hm>
- Date
- Jan 17, 2013, 01:26 UTC
- Message-ID
- <alpine.DEB.2.02.1301161721110.21503@nftneq.ynat.uz>
- In-Reply-To
- <A0DB01D693D8EF439496BC8B037A0AEF32209A54@xmb-rcd-x15.cisco.com>
On Thu, 17 Jan 2013, Matt Seitz (matseitz) wrote:
Show 29 quoted lines
>> From: David Lang [mailto:david@lang.hm] >> >> On Wed, 16 Jan 2013, Matt Seitz (matseitz) wrote: >> >>> Linus seemed to think it should work: >>> >>> http://permalink.gmane.org/gmane.comp.version-control.git/122670 >> >> In the link you point at, he says that you can have problems with some >> types of >> actions. He points out things like git prune, > > Linus wrote: > > You do need to be a bit careful if you do maintenance operations > concurrently (I would suggest avoiding doing concurrent "git gc --prune", > for example), but any normal git workflow should be fine. > >> but I would also say that there >> are probably race conditions if you have two git processes that try to >> change the HEAD to different things at the same time. > > What makes you think there are race conditions? > > Linus wrote: > > And git doesn't have "proper locking", because it doesn't need it for > database ops: git objects are stable. For refs, git should be using the > proper NFS-safe "create and atomic rename" ops.
As Linus points out, objects are stable, so when you create objects you don't have to worry about locking, if two things write an object at the same time, the same contents are being written so races don't matter.
However, if you have two people doing a commit or merge, you will get different results based on the order they are happening in. This seems to be exactly the type of thing that falls into the 'maintinance operations' category.
Linus says that git does not have "proper locking", so think about it, what do you think will happen if person A does git add a/b; git commit and person B does git add c/d; git commit?
Since the tree will look different depending on what order these four commands execute in, the resulting HEAD could have multiple different values depending on the order. The individual commits may even be different.
David Lang
Show 11 quoted lines
>>> And "git init" specifically has a "shared" option: >>> >>> --shared[=(false|true|umask|group|all|world|everybody|0xxx)] >> >> I think this is dealing with multiple users _reading_ a repository, not >> making >> updates to it at the same time. > > The description of "shared" says "This allows users belonging to the same > group to push into that repository." The "push" command is about making > updates.