Managing websites with git

Hi!

Is it a bad idea to manage websites (php/xhtml/css) by having a origin
non-bare repo in the hosted dir with the hook mentioned here:
http://git.or.cz/gitwiki/GitFaq#head-b96f48bc9c925074be9f95c0fce69bcece5f6e73.
I was thinking about any security issues with the .git dir being
hosted. Or is that even the right way to do it?

Thank you
Felix Andersen

Hello,

On Sun, Nov 30, 2008 at 05:30:30PM +0100 or thereabouts, Felix Andersen wrote:

Hi!

Is it a bad idea to manage websites (php/xhtml/css) by having a origin
non-bare repo in the hosted dir with the hook mentioned here:
http://git.or.cz/gitwiki/GitFaq#head-b96f48bc9c925074be9f95c0fce69bcece5f6e73.
I was thinking about any security issues with the .git dir being
hosted. Or is that even the right way to do it?

One really should not push to a non-bare repo.  IIRC there was a patch
recently to disallow it, but I do not remember if it was merged into
HEAD.

Since I knew the patch was coming I rewrote my scripts to use a bare
repo in /var/git, and push the changes to /var/www whenever I push to
the remote repo.

I wrote my post-update to be something like the following.

#!/bin/bash
LIVE="/var/www/statichacks/blosxom"

ref=$1

cd $GIT_DIR
echo "Pushing updates to $LIVE..."
git archive --format=tar $ref | tar -C $LIVE --atime-preserve -xpf -

There may be an easier way to do it, but that script took me about 5
minutes to write and test.

Dave

On Sun, Nov 30, 2008 at 09:07:22AM -0800, David Bryson wrote:

One really should not push to a non-bare repo.  IIRC there was a patch
recently to disallow it, but I do not remember if it was merged into
HEAD.

It's in master and should be in 1.6.1, but it is a config option that
defaults to "warn" for now, so as not to break existing setups. It may
switch to "refuse" after a deprecation period, but I don't think the
length of that period has been set.

Since I knew the patch was coming I rewrote my scripts to use a bare
repo in /var/git, and push the changes to /var/www whenever I push to
the remote repo.

Personally, I think that is a sane way to go; but note that you still
use a non-bare repo with a checkout hook by explicitly setting
receive.denyCurrentBranch to false.

#!/bin/bash
LIVE="/var/www/statichacks/blosxom"

ref=$1

cd $GIT_DIR
echo "Pushing updates to $LIVE..."
git archive --format=tar $ref | tar -C $LIVE --atime-preserve -xpf -

There may be an easier way to do it, but that script took me about 5
minutes to write and test.

One disadvantage of this method is that it doesn't remove files from
$LIVE that were deleted in the repository.

-Peff

On Sun, Nov 30, 2008 at 05:30:30PM +0100, Felix Andersen wrote:

I was thinking about any security issues with the .git dir being
hosted. Or is that even the right way to do it?

With Apache, you can add the following to your httpd.conf file, or to an
.htaccess file within your document root:

    <DirectoryMatch "^\.git">
	Order allow,deny
	Deny from all
    </DirectoryMatch>
    <FilesMatch "^\.gitignore">
	Order allow,deny
	Deny from all
    </FilesMatch>

to prevent web access to the respository.

-- 
"Oh, look: rocks!"
	-- Doctor Who, "Destiny of the Daleks"