Re: How to set up a shared repository

[Junio C Hamano <junkio@cox.net>]

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

> 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 ;-)

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