Re: How to set up a shared repository

From: Junio C Hamano <junkio@cox.net>
Date: Dec 21, 2005, 20:56 UTC
Message-ID: <7vy82e5ftx.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.63.0512211919040.16640@wbgn013.biozentrum.uni-wuerzburg.de>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 10 quoted lines

> A. Setting up the umask
>
> 1. Separate repository box
>
> If you are lucky enough that you can afford a separate machine for the 
> shared repository: Good. Just make sure that the umask is set group 
> friendly, either by ensuring that (assuming the login shell is bash) 
> $HOME/.bash_profile contains the line
>
> 	umask 0002

I suspect a bash started from ssh noninteractive session does not read .bash_profile --- you may want to check.

> 2. Some server accessible by ssh
>
> 	git-repo-config core.umask 0002

Not yet ;-)

Show 12 quoted lines

> B. Making sure the index is not corrupted by a push
>
> 1. No checkout!
>
> You can use the shared repository just like you use CVS: no working 
> directory. To disallow a checkout, just do
>
> 	touch .git/index
> 	chmod a-rwx .git/index
>
> Every attempt to modify the index (which is invalid), will now result in 
> an error.

Arrrgh....what a hack.  But it is a good hack.

> 2. Ensure index and working directory consistency (no locking)
>
> If you want to be able to work on the project in the shared repository,

I am very tempted to end this sentence with "please don't" ;-).

> create hooks, as follows:

Your update hook looks sane if too strict. I do not think of any reason to push and fast forward a branch that is not pointed at by .git/HEAD. Not that I encourage pushing into a non-naked repository where an uncontrolled random development happens, though.

> Note that I did not check if a push locks another push.

Although it does protect against stomping on each other by read/do-work/re-read-and-swap cycle, push does not lock. If you want to run a build from the post-update hook you need to serialize the build yourself.