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