RE: Question re. git remote repository

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 17 Jan 2013, Matt Seitz (matseitz) wrote:

From: David Lang [mailto:david@xxxxxxx]

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

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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]