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:

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:

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.

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.

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

-Peff

And David Bryson writes:

WHAT?!?!?!

And Jeff King responds:

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

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

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

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

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?

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.

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

And Jeff King writes:

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

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

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

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

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

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.

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.

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

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

Jeff King <peff@peff.net> writes:

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.

On 12/1/08, Jason Riedy <jason@acm.org> wrote:

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

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

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.