{"thread":{"id":"16529","subject":"Managing websites with git","startedAt":"2008-11-30T16:30:30Z","lastAt":"2009-01-03T21:29:08Z","messageCount":10,"participants":["Felix Andersen","David Bryson","Jeff King","Jason Riedy","Leo Razoumov","Junio C Hamano","Todd A. Jacobs"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"96787","messageId":"fe5a74300811300830x850d81csc5cf1f9b367bac11@mail.gmail.com","threadId":"16529","inReplyTo":null,"subject":"Managing websites with git","fromName":"Felix Andersen","fromEmail":"felix@nibbo.se","sentAt":"2008-11-30T16:30:30Z","receivedAt":"2008-11-30T16:30:30Z","isPatch":false,"sender":{"key":"felix@nibbo.se","avatar":null},"body":"Hi!\n\nIs it a bad idea to manage websites (php/xhtml/css) by having a origin\nnon-bare repo in the hosted dir with the hook mentioned here:\nhttp://git.or.cz/gitwiki/GitFaq#head-b96f48bc9c925074be9f95c0fce69bcece5f6e73.\nI was thinking about any security issues with the .git dir being\nhosted. Or is that even the right way to do it?\n\nThank you\nFelix Andersen\n"},{"id":"96788","messageId":"20081130170722.GJ6572@eratosthenes.sbcglobal.net","threadId":"16529","inReplyTo":"fe5a74300811300830x850d81csc5cf1f9b367bac11@mail.gmail.com","subject":"Re: Managing websites with git","fromName":"David Bryson","fromEmail":"david@statichacks.org","sentAt":"2008-11-30T17:07:22Z","receivedAt":"2008-11-30T17:07:22Z","isPatch":false,"sender":{"key":"david@statichacks.org","avatar":"https://gravatar.com/avatar/b8796a0b286799d99dcbaea3fd3e8675648cc094ff10b07bae8fe3bc0ac40b9c?d=mp&s=160"},"body":"Hello,\n\nOn Sun, Nov 30, 2008 at 05:30:30PM +0100 or thereabouts, Felix Andersen wrote:\n> Hi!\n> \n> Is it a bad idea to manage websites (php/xhtml/css) by having a origin\n> non-bare repo in the hosted dir with the hook mentioned here:\n> http://git.or.cz/gitwiki/GitFaq#head-b96f48bc9c925074be9f95c0fce69bcece5f6e73.\n> I was thinking about any security issues with the .git dir being\n> hosted. Or is that even the right way to do it?\n> \n\nOne really should not push to a non-bare repo.  IIRC there was a patch\nrecently to disallow it, but I do not remember if it was merged into\nHEAD.\n\nSince I knew the patch was coming I rewrote my scripts to use a bare\nrepo in /var/git, and push the changes to /var/www whenever I push to\nthe remote repo.\n\nI wrote my post-update to be something like the following.\n\n#!/bin/bash\nLIVE=\"/var/www/statichacks/blosxom\"\n\nref=$1\n\ncd $GIT_DIR\necho \"Pushing updates to $LIVE...\"\ngit archive --format=tar $ref | tar -C $LIVE --atime-preserve -xpf -\n\nThere may be an easier way to do it, but that script took me about 5\nminutes to write and test.\n\nDave\n\n"},{"id":"96789","messageId":"20081130172717.GA7047@coredump.intra.peff.net","threadId":"16529","inReplyTo":"20081130170722.GJ6572@eratosthenes.sbcglobal.net","subject":"Re: Managing websites with git","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-11-30T17:27:17Z","receivedAt":"2008-11-30T17:27:17Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Nov 30, 2008 at 09:07:22AM -0800, David Bryson wrote:\n\n> One really should not push to a non-bare repo.  IIRC there was a patch\n> recently to disallow it, but I do not remember if it was merged into\n> HEAD.\n\nIt's in master and should be in 1.6.1, but it is a config option that\ndefaults to \"warn\" for now, so as not to break existing setups. It may\nswitch to \"refuse\" after a deprecation period, but I don't think the\nlength of that period has been set.\n\n> Since I knew the patch was coming I rewrote my scripts to use a bare\n> repo in /var/git, and push the changes to /var/www whenever I push to\n> the remote repo.\n\nPersonally, I think that is a sane way to go; but note that you still\nuse a non-bare repo with a checkout hook by explicitly setting\nreceive.denyCurrentBranch to false.\n\n> #!/bin/bash\n> LIVE=\"/var/www/statichacks/blosxom\"\n> \n> ref=$1\n> \n> cd $GIT_DIR\n> echo \"Pushing updates to $LIVE...\"\n> git archive --format=tar $ref | tar -C $LIVE --atime-preserve -xpf -\n> \n> There may be an easier way to do it, but that script took me about 5\n> minutes to write and test.\n\nOne disadvantage of this method is that it doesn't remove files from\n$LIVE that were deleted in the repository.\n\n-Peff\n"},{"id":"96896","messageId":"87k5ajflp0.fsf@sparse.dyndns.org","threadId":"16529","inReplyTo":"20081130172717.GA7047@coredump.intra.peff.net","subject":"Re: Managing websites with git","fromName":"Jason Riedy","fromEmail":"jason@acm.org","sentAt":"2008-12-02T00:46:35Z","receivedAt":"2008-12-02T00:46:35Z","isPatch":false,"sender":{"key":"jason@acm.org","avatar":"https://gravatar.com/avatar/7e80c271425fe9c47df4cb7cfaae91c4e7ac96badee28ad2c1fdd6f9916a54b0?d=mp&s=160"},"body":"And David Bryson writes:\n> One really should not push to a non-bare repo.\n\nWHAT?!?!?!\n\nAnd Jeff King responds:\n> It's in master and should be in 1.6.1, but it is a config option that\n> defaults to \"warn\" for now, so as not to break existing setups.\n\nWHAT?!?!?!\n\nI do this all the time.  I clone from my main working directory\nonto some cluster / MPP where the build system is all wonky.\nOnce I get everything building, I push back to a branch (often\nnew) in my main working directory.  Then I can merge the build\nchanges whenever I get a chance.\n\nPushing from these systems often is much, much easier than\npulling from the origin.  Sometimes you're working in temporary\nspace on a back-end node; you can connect out but you cannot\nconnect in.\n\nI've gotten a few people interested in git for managing these\nnearly one-off build problems.  git is the first system that has\n\"just worked\" for them.  Their having to configure each repo\neliminates the \"just works\" factor.\n\nIt feels like newer gits make more and more decisions about what\nI shouldn't do.\n\nJason\n"},{"id":"96893","messageId":"20081202011154.GA6390@coredump.intra.peff.net","threadId":"16529","inReplyTo":"87k5ajflp0.fsf@sparse.dyndns.org","subject":"Re: Managing websites with git","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-12-02T01:11:54Z","receivedAt":"2008-12-02T01:11:54Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Dec 01, 2008 at 07:46:35PM -0500, Jason Riedy wrote:\n\n> And David Bryson writes:\n> > One really should not push to a non-bare repo.\n> WHAT?!?!?!\n\nTo clarify: one should not push to the _current branch_ of a non-bare\nrepo...\n\n> And Jeff King responds:\n> > It's in master and should be in 1.6.1, but it is a config option that\n> > defaults to \"warn\" for now, so as not to break existing setups.\n> WHAT?!?!?!\n\n...and that is what 1.6.1 will warn about.\n\n> I do this all the time.  I clone from my main working directory\n> onto some cluster / MPP where the build system is all wonky.\n> Once I get everything building, I push back to a branch (often\n> new) in my main working directory.  Then I can merge the build\n> changes whenever I get a chance.\n\nAs long as you are not pushing to the currently checked-out branch, then\nyou will see no change in behavior. If you are pushing to the currently\nchecked-out branch, then what are you doing to reconcile the resulting\nmismatch between the index and HEAD?\n\n> Pushing from these systems often is much, much easier than\n> pulling from the origin.  Sometimes you're working in temporary\n> space on a back-end node; you can connect out but you cannot\n> connect in.\n\nOf course. The recommended thing to do is:\n\n  # on pusher\n  git push $remote HEAD:some-branch-that-is-not-checked-out\n  # on $remote\n  git merge some-branch-that-is-not-checked-out\n\nwhere an obvious choice for branch name is \"incoming/master\" or whatever\nsuits your workflow. You can also do:\n\n  # on pusher\n  git push $remote HEAD:branch-that-is-checked-out\n  # on $remote\n  git reset --hard\n\nbut that throws away anything else going on in that branch on $remote.\n\n> It feels like newer gits make more and more decisions about what\n> I shouldn't do.\n\nDoing\n\n  git push $remote HEAD:branch-that-is-checked-out\n\nhas _never_ worked without further action on $remote. Now we're warning\nabout it.\n\nIf you have other specific complaints about new git behavior, I'm sure\nthe list would be happy to hear about it. Almost every behavior change\nis in response to user complaints, and a lot of effort is put into\nmaintaining backwards compatibility. If we've screwed up somewhere, it\nwould be good to know.\n\n-Peff\n"},{"id":"96899","messageId":"ee2a733e0812011736o122b43bbxb30a92261f584370@mail.gmail.com","threadId":"16529","inReplyTo":"87k5ajflp0.fsf@sparse.dyndns.org","subject":"Re: Managing websites with git","fromName":"Leo Razoumov","fromEmail":"slonik.az@gmail.com","sentAt":"2008-12-02T01:36:43Z","receivedAt":"2008-12-02T01:36:43Z","isPatch":false,"sender":{"key":"slonik.az@gmail.com","avatar":null},"body":"On 12/1/08, Jason Riedy <jason@acm.org> wrote:\n> And David Bryson writes:\n>  > One really should not push to a non-bare repo.\n>\n>\n> WHAT?!?!?!\n>\n>  And Jeff King responds:\n>\n> > It's in master and should be in 1.6.1, but it is a config option that\n>  > defaults to \"warn\" for now, so as not to break existing setups.\n>\n>\n> WHAT?!?!?!\n>\n>  I do this all the time.  I clone from my main working directory\n>  onto some cluster / MPP where the build system is all wonky.\n>  Once I get everything building, I push back to a branch (often\n>  new) in my main working directory.  Then I can merge the build\n>  changes whenever I get a chance.\n>\n>  Pushing from these systems often is much, much easier than\n>  pulling from the origin.  Sometimes you're working in temporary\n>  space on a back-end node; you can connect out but you cannot\n>  connect in.\n>\n>  I've gotten a few people interested in git for managing these\n>  nearly one-off build problems.  git is the first system that has\n>  \"just worked\" for them.  Their having to configure each repo\n>  eliminates the \"just works\" factor.\n>\n>  It feels like newer gits make more and more decisions about what\n>  I shouldn't do.\n>\n>\n>  Jason\n>\n\nI second Jason's opinion. I also frequently push to non-bare\nintermediary repos. This functionality is essential for several of my\nwork flows. Please, please, do not handicap git-push operation!!\n\n--Leo--\n"},{"id":"96963","messageId":"87vdu2po5l.fsf@sparse.dyndns.org","threadId":"16529","inReplyTo":"20081202011154.GA6390@coredump.intra.peff.net","subject":"Re: Managing websites with git","fromName":"Jason Riedy","fromEmail":"jason@acm.org","sentAt":"2008-12-02T15:55:34Z","receivedAt":"2008-12-02T15:55:34Z","isPatch":false,"sender":{"key":"jason@acm.org","avatar":"https://gravatar.com/avatar/7e80c271425fe9c47df4cb7cfaae91c4e7ac96badee28ad2c1fdd6f9916a54b0?d=mp&s=160"},"body":"And Jeff King writes:\n> To clarify: one should not push to the _current branch_ of a\n> non-bare repo...\n\nAh, ok, thanks!  Issuing a warning makes sense.  I'm not sure if\ndenying such a push by default does...\n\n> Doing git push $remote HEAD:branch-that-is-checked-out\n> has _never_ worked without further action on $remote. Now we're warning\n> about it.\n\nIt works just fine.  I suspect we have different definitions of\n\"works\".\n\nTo me, that push updates the branch's reference.  The working\ncopy and index now may be out of sync, but neither the working\ncopy nor the index is the branch's reference.  Trying to commit\nfrom the index correctly refuses.  The warning is a nice\nreminder, but I don't see why this should be denied by default.\nThe user (me) hasn't lost anything, and every tool does what it\nis supposed to do (from my point of view).\n\nBut I'm one of those people who has always liked the three levels\nof git.  And I use them all.\n\n(And in context: I used to update the IEEE754 group's web site by\na git push to the checked-out master, with a hook to reset\neverything.  Worked just fine (and very quickly) until they shut\noff shell access.  There was no need for an extra branch on the\nserver side.)\n\n> If you have other specific complaints about new git behavior,\n> I'm sure the list would be happy to hear about it.\n\nI'll try to find time when I encounter another.  I'm pretty sure\nthat switching to denying pushes to checked-out branches is the\nfirst one that *really* will make me change how I work.\n\nJason\n"},{"id":"96966","messageId":"20081202165507.GA15826@coredump.intra.peff.net","threadId":"16529","inReplyTo":"87vdu2po5l.fsf@sparse.dyndns.org","subject":"Re: Managing websites with git","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-12-02T16:55:07Z","receivedAt":"2008-12-02T16:55:07Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Dec 02, 2008 at 10:55:34AM -0500, Jason Riedy wrote:\n\n> Ah, ok, thanks!  Issuing a warning makes sense.  I'm not sure if\n> denying such a push by default does...\n\nI don't know if Junio has made a decision on whether or when the default\nshould be flipped to 'deny'.\n\n> > Doing git push $remote HEAD:branch-that-is-checked-out\n> > has _never_ worked without further action on $remote. Now we're warning\n> > about it.\n> \n> It works just fine.  I suspect we have different definitions of\n> \"works\".\n\nFair enough. To be more precise: such a push has always resulted in a\nstate on the remote end that the user must be aware of when making\nfurther commits, and the result of _not_ being aware and blindly running\n\"git commit\" is to accidentally revert all of the pushed changes. And\neven if one _is_ aware, sorting out any existing changes in the index\nfrom pushed changes can be difficult.\n\nSo yes, there are workflows that can legitimately make use of a push to\nthe current branch. But it is still a dangerous operation for a large\nnumber of users (I would argue the majority, but I don't have actual\nnumbers) that we have seen numerous complaints about.\n\n> To me, that push updates the branch's reference.  The working\n> copy and index now may be out of sync, but neither the working\n> copy nor the index is the branch's reference.  Trying to commit\n> from the index correctly refuses.  The warning is a nice\n\nHow is committing from the index refused? Try this:\n\n  mkdir parent &&\n  (cd parent &&\n    git init &&\n    echo content >file &&\n    git add file &&\n    git commit -m one) &&\n  git clone parent child &&\n  (cd child &&\n    echo changes >>file &&\n    git commit -a -m two &&\n    git push) &&\n  (cd parent &&\n    git commit -m oops &&\n    git show\n  )\n\nYou will find that you have just reverted the changes from 'two' with\n'oops'.\n\nCommitting straight from the working tree (via \"git commit <path>\" or\n\"git commit -a\") has the same problem.\n\n> (And in context: I used to update the IEEE754 group's web site by\n> a git push to the checked-out master, with a hook to reset\n> everything.  Worked just fine (and very quickly) until they shut\n> off shell access.  There was no need for an extra branch on the\n> server side.)\n\nFollow the earlier parts of the thread and you will see that is one of\nthe sane workflows that has been mentioned. You are aware of the lack of\nsync (and you have a hook to address it) and you don't plan on having\nany local changes (so sorting them out is easy -- you just \"git reset\n--hard\" to take the pushed content).\n\n> I'll try to find time when I encounter another.  I'm pretty sure\n> that switching to denying pushes to checked-out branches is the\n> first one that *really* will make me change how I work.\n\nIt shouldn't make you change how you work. At most, it will break an\nexisting setup until you set receive.denycurrentbranch to false (again,\nif and when the default value changes). You can prepare for any such\nchange now by pre-emptively setting the config value.\n\n-Peff\n"},{"id":"96975","messageId":"7vd4gapf91.fsf@gitster.siamese.dyndns.org","threadId":"16529","inReplyTo":"20081202165507.GA15826@coredump.intra.peff.net","subject":"Re: Managing websites with git","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-12-02T19:07:54Z","receivedAt":"2008-12-02T19:07:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Tue, Dec 02, 2008 at 10:55:34AM -0500, Jason Riedy wrote:\n>\n>> Ah, ok, thanks!  Issuing a warning makes sense.  I'm not sure if\n>> denying such a push by default does...\n> ...\n> It shouldn't make you change how you work. At most, it will break an\n> existing setup until you set receive.denycurrentbranch to false (again,\n> if and when the default value changes). You can prepare for any such\n> change now by pre-emptively setting the config value.\n\nTrue.\n\nBut \"pre-emptively\" is a bit misleading.  Please realize that the warning\nis not about \"this is a risky thing to do, you've been warned\", but is\nabout \"the behaviour to allow this may change in the future; if you rely\non it please set this config before that happens\".  We may end up not\nflipping the default for a long time, but setting the config also has the\nside effect of squelching the warning, so it never hurts to set it now.\n"},{"id":"99265","messageId":"20090103212908.GG6136@penguin.codegnome.org","threadId":"16529","inReplyTo":"fe5a74300811300830x850d81csc5cf1f9b367bac11@mail.gmail.com","subject":"Re: Managing websites with git","fromName":"Todd A. Jacobs","fromEmail":"nospam@codegnome.org","sentAt":"2009-01-03T21:29:08Z","receivedAt":"2009-01-03T21:29:08Z","isPatch":false,"sender":{"key":"nospam@codegnome.org","avatar":null},"body":"On Sun, Nov 30, 2008 at 05:30:30PM +0100, Felix Andersen wrote:\n\n> I was thinking about any security issues with the .git dir being\n> hosted. Or is that even the right way to do it?\n\nWith Apache, you can add the following to your httpd.conf file, or to an\n.htaccess file within your document root:\n\n    <DirectoryMatch \"^\\.git\">\n\tOrder allow,deny\n\tDeny from all\n    </DirectoryMatch>\n    <FilesMatch \"^\\.gitignore\">\n\tOrder allow,deny\n\tDeny from all\n    </FilesMatch>\n\nto prevent web access to the respository.\n\n-- \n\"Oh, look: rocks!\"\n\t-- Doctor Who, \"Destiny of the Daleks\"\n"}]}