RE: Question re. git remote repository

From: Matt Seitz (matseitz) <matseitz@cisco.com>
Date: Jan 17, 2013, 01:09 UTC
Message-ID: <A0DB01D693D8EF439496BC8B037A0AEF32209A54@xmb-rcd-x15.cisco.com>
In-Reply-To: <alpine.DEB.2.02.1301161617240.21503@nftneq.ynat.uz>

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

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