Managing websites with git

Managing websites with git

[Felix Andersen]

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

Re: Managing websites with git

[David Bryson]

[-- Attachment #1: Type: text/plain, Size: 1112 bytes --]

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


[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Managing websites with git

[Jeff King]

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

Re: Managing websites with git

[Jason Riedy]

And David Bryson writes:
> One really should not push to a non-bare repo.

WHAT?!?!?!

And Jeff King responds:
> 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.

WHAT?!?!?!

I do this all the time.  I clone from my main working directory
onto some cluster / MPP where the build system is all wonky.
Once I get everything building, I push back to a branch (often
new) in my main working directory.  Then I can merge the build
changes whenever I get a chance.

Pushing from these systems often is much, much easier than
pulling from the origin.  Sometimes you're working in temporary
space on a back-end node; you can connect out but you cannot
connect in.

I've gotten a few people interested in git for managing these
nearly one-off build problems.  git is the first system that has
"just worked" for them.  Their having to configure each repo
eliminates the "just works" factor.

It feels like newer gits make more and more decisions about what
I shouldn't do.

Jason

Re: Managing websites with git

[Jeff King]

On Mon, Dec 01, 2008 at 07:46:35PM -0500, Jason Riedy wrote:

> And David Bryson writes:
> > One really should not push to a non-bare repo.
> WHAT?!?!?!

To clarify: one should not push to the _current branch_ of a non-bare
repo...

> And Jeff King responds:
> > 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.
> WHAT?!?!?!

...and that is what 1.6.1 will warn about.

> I do this all the time.  I clone from my main working directory
> onto some cluster / MPP where the build system is all wonky.
> Once I get everything building, I push back to a branch (often
> new) in my main working directory.  Then I can merge the build
> changes whenever I get a chance.

As long as you are not pushing to the currently checked-out branch, then
you will see no change in behavior. If you are pushing to the currently
checked-out branch, then what are you doing to reconcile the resulting
mismatch between the index and HEAD?

> Pushing from these systems often is much, much easier than
> pulling from the origin.  Sometimes you're working in temporary
> space on a back-end node; you can connect out but you cannot
> connect in.

Of course. The recommended thing to do is:

  # on pusher
  git push $remote HEAD:some-branch-that-is-not-checked-out
  # on $remote
  git merge some-branch-that-is-not-checked-out

where an obvious choice for branch name is "incoming/master" or whatever
suits your workflow. You can also do:

  # on pusher
  git push $remote HEAD:branch-that-is-checked-out
  # on $remote
  git reset --hard

but that throws away anything else going on in that branch on $remote.

> It feels like newer gits make more and more decisions about what
> I shouldn't do.

Doing

  git push $remote HEAD:branch-that-is-checked-out

has _never_ worked without further action on $remote. Now we're warning
about it.

If you have other specific complaints about new git behavior, I'm sure
the list would be happy to hear about it. Almost every behavior change
is in response to user complaints, and a lot of effort is put into
maintaining backwards compatibility. If we've screwed up somewhere, it
would be good to know.

-Peff

Re: Managing websites with git

[Leo Razoumov]

On 12/1/08, Jason Riedy <jason@acm.org> wrote:
> And David Bryson writes:
>  > One really should not push to a non-bare repo.
>
>
> WHAT?!?!?!
>
>  And Jeff King responds:
>
> > 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.
>
>
> WHAT?!?!?!
>
>  I do this all the time.  I clone from my main working directory
>  onto some cluster / MPP where the build system is all wonky.
>  Once I get everything building, I push back to a branch (often
>  new) in my main working directory.  Then I can merge the build
>  changes whenever I get a chance.
>
>  Pushing from these systems often is much, much easier than
>  pulling from the origin.  Sometimes you're working in temporary
>  space on a back-end node; you can connect out but you cannot
>  connect in.
>
>  I've gotten a few people interested in git for managing these
>  nearly one-off build problems.  git is the first system that has
>  "just worked" for them.  Their having to configure each repo
>  eliminates the "just works" factor.
>
>  It feels like newer gits make more and more decisions about what
>  I shouldn't do.
>
>
>  Jason
>

I second Jason's opinion. I also frequently push to non-bare
intermediary repos. This functionality is essential for several of my
work flows. Please, please, do not handicap git-push operation!!

--Leo--

Re: Managing websites with git

[Jason Riedy]

And Jeff King writes:
> To clarify: one should not push to the _current branch_ of a
> non-bare repo...

Ah, ok, thanks!  Issuing a warning makes sense.  I'm not sure if
denying such a push by default does...

> Doing git push $remote HEAD:branch-that-is-checked-out
> has _never_ worked without further action on $remote. Now we're warning
> about it.

It works just fine.  I suspect we have different definitions of
"works".

To me, that push updates the branch's reference.  The working
copy and index now may be out of sync, but neither the working
copy nor the index is the branch's reference.  Trying to commit
from the index correctly refuses.  The warning is a nice
reminder, but I don't see why this should be denied by default.
The user (me) hasn't lost anything, and every tool does what it
is supposed to do (from my point of view).

But I'm one of those people who has always liked the three levels
of git.  And I use them all.

(And in context: I used to update the IEEE754 group's web site by
a git push to the checked-out master, with a hook to reset
everything.  Worked just fine (and very quickly) until they shut
off shell access.  There was no need for an extra branch on the
server side.)

> If you have other specific complaints about new git behavior,
> I'm sure the list would be happy to hear about it.

I'll try to find time when I encounter another.  I'm pretty sure
that switching to denying pushes to checked-out branches is the
first one that *really* will make me change how I work.

Jason

Re: Managing websites with git

[Jeff King]

On Tue, Dec 02, 2008 at 10:55:34AM -0500, Jason Riedy wrote:

> Ah, ok, thanks!  Issuing a warning makes sense.  I'm not sure if
> denying such a push by default does...

I don't know if Junio has made a decision on whether or when the default
should be flipped to 'deny'.

> > Doing git push $remote HEAD:branch-that-is-checked-out
> > has _never_ worked without further action on $remote. Now we're warning
> > about it.
> 
> It works just fine.  I suspect we have different definitions of
> "works".

Fair enough. To be more precise: such a push has always resulted in a
state on the remote end that the user must be aware of when making
further commits, and the result of _not_ being aware and blindly running
"git commit" is to accidentally revert all of the pushed changes. And
even if one _is_ aware, sorting out any existing changes in the index
from pushed changes can be difficult.

So yes, there are workflows that can legitimately make use of a push to
the current branch. But it is still a dangerous operation for a large
number of users (I would argue the majority, but I don't have actual
numbers) that we have seen numerous complaints about.

> To me, that push updates the branch's reference.  The working
> copy and index now may be out of sync, but neither the working
> copy nor the index is the branch's reference.  Trying to commit
> from the index correctly refuses.  The warning is a nice

How is committing from the index refused? Try this:

  mkdir parent &&
  (cd parent &&
    git init &&
    echo content >file &&
    git add file &&
    git commit -m one) &&
  git clone parent child &&
  (cd child &&
    echo changes >>file &&
    git commit -a -m two &&
    git push) &&
  (cd parent &&
    git commit -m oops &&
    git show
  )

You will find that you have just reverted the changes from 'two' with
'oops'.

Committing straight from the working tree (via "git commit <path>" or
"git commit -a") has the same problem.

> (And in context: I used to update the IEEE754 group's web site by
> a git push to the checked-out master, with a hook to reset
> everything.  Worked just fine (and very quickly) until they shut
> off shell access.  There was no need for an extra branch on the
> server side.)

Follow the earlier parts of the thread and you will see that is one of
the sane workflows that has been mentioned. You are aware of the lack of
sync (and you have a hook to address it) and you don't plan on having
any local changes (so sorting them out is easy -- you just "git reset
--hard" to take the pushed content).

> I'll try to find time when I encounter another.  I'm pretty sure
> that switching to denying pushes to checked-out branches is the
> first one that *really* will make me change how I work.

It shouldn't make you change how you work. At most, it will break an
existing setup until you set receive.denycurrentbranch to false (again,
if and when the default value changes). You can prepare for any such
change now by pre-emptively setting the config value.

-Peff

Re: Managing websites with git

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Tue, Dec 02, 2008 at 10:55:34AM -0500, Jason Riedy wrote:
>
>> Ah, ok, thanks!  Issuing a warning makes sense.  I'm not sure if
>> denying such a push by default does...
> ...
> It shouldn't make you change how you work. At most, it will break an
> existing setup until you set receive.denycurrentbranch to false (again,
> if and when the default value changes). You can prepare for any such
> change now by pre-emptively setting the config value.

True.

But "pre-emptively" is a bit misleading.  Please realize that the warning
is not about "this is a risky thing to do, you've been warned", but is
about "the behaviour to allow this may change in the future; if you rely
on it please set this config before that happens".  We may end up not
flipping the default for a long time, but setting the config also has the
side effect of squelching the warning, so it never hurts to set it now.

Re: Managing websites with git

[Todd A. Jacobs]

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"