On Tuesday 2007 February 13 15:11, Johannes Schindelin wrote:
> Since ref updates are not write-into-existing-file, but rather
> write-into-new-file-and-replace-old, it should work, no?
That perhaps might be the explanation for the bad behaviour. The ref is being
updated in git-cvsserver by writing the new head hash into the lockfile then
doing
unlink($reffile);
rename($lockfile, $reffile);
The lockfile is made with whatever umask is in place, so the
sharedrepository=group is being ignored. The solution then is to use the
permissions of the existing reffile when creating the lockfile.
Thanks Johannes. One little sentence and it all becomes clear :-)
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
andyparkins@xxxxxxxxx
-
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