{"thread":{"id":"23025","subject":"git http-backend error message","startedAt":"2010-03-15T16:13:55Z","lastAt":"2010-04-05T14:52:47Z","messageCount":4,"participants":["Jeremiah Foster","Junio C Hamano","Scott R. Godin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"136842","messageId":"A55E5483-425E-4303-87F2-FABC46F6BFE5@pelagicore.com","threadId":"23025","inReplyTo":null,"subject":"git http-backend error message","fromName":"Jeremiah Foster","fromEmail":"jeremiah.foster@pelagicore.com","sentAt":"2010-03-15T16:13:55Z","receivedAt":"2010-03-15T16:13:55Z","isPatch":false,"sender":{"key":"jeremiah.foster@pelagicore.com","avatar":"https://gravatar.com/avatar/f107bff0d3617df3e171850d6ae81df4acb6767072fe7435a8c9f22b3824e5bd?d=mp&s=160"},"body":"Hello,\n\n\tI've recently installed git 1.7.0.2 to enable serving git repositories in an efficient fashion over http. Thanks to the excellent documentation here: http://www.kernel.org/pub/software/scm/git/docs/git-http-backend.html I was able to set up the git repo with ldap on debian with apache2 fairly quickly. \n\n\tWhat I cannot do is push back to the repo. I can check out a complete git repo, add to it, commit. But when I do;\n\n\t'git push origin master' \n\n\tI get this error:\n\nerror: refusing to update checked out branch: refs/heads/master\nerror: By default, updating the current branch in a non-bare repository\nerror: is denied, because it will make the index and work tree inconsistent\nerror: with what you pushed, and will require 'git reset --hard' to match\nerror: the work tree to HEAD.\nerror: \nerror: You can set 'receive.denyCurrentBranch' configuration variable to\nerror: 'ignore' or 'warn' in the remote repository to allow pushing into\nerror: its current branch; however, this is not recommended unless you\nerror: arranged to update its work tree to match what you pushed in some\nerror: other way.\nerror: \nerror: To squelch this message and still keep the default behaviour, set\nerror: 'receive.denyCurrentBranch' configuration variable to 'refuse'.\n\n\tI am unclear about my next move. Should I just set receive.denyCurrentBranch to 'warn' and then my commits locally will go back up to the server? \n\tOr is it smarter to just create a bare repository, clone some content into it, and then push?\n\nThanks,\n\n\tJeremiah"},{"id":"136845","messageId":"7v3a01v796.fsf@alter.siamese.dyndns.org","threadId":"23025","inReplyTo":"A55E5483-425E-4303-87F2-FABC46F6BFE5@pelagicore.com","subject":"Re: git http-backend error message","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-03-15T17:12:37Z","receivedAt":"2010-03-15T17:12:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeremiah Foster <jeremiah.foster@pelagicore.com> writes:\n\n> error: refusing to update checked out branch: refs/heads/master\n> error: By default, updating the current branch in a non-bare repository\n> error: is denied, because it will make the index and work tree inconsistent\n> error: with what you pushed, and will require 'git reset --hard' to match\n> error: the work tree to HEAD.\n> error: \n> error: You can set 'receive.denyCurrentBranch' configuration variable to\n> error: 'ignore' or 'warn' in the remote repository to allow pushing into\n> error: its current branch; however, this is not recommended unless you\n> error: arranged to update its work tree to match what you pushed in some\n> error: other way.\n> error: \n> error: To squelch this message and still keep the default behaviour, set\n> error: 'receive.denyCurrentBranch' configuration variable to 'refuse'.\n>\n> \tI am unclear about my next move. Should I just set\n> \treceive.denyCurrentBranch to 'warn' and then my commits locally\n> \twill go back up to the server?\n\nAfter it becomes clear about your next move (people will try to help you\nin this thread), please also tell us what information you found lacking in\nthe above advisory text that you had to ask this question.  The message is\ntrying to help you decide what your next move should be, but apparently\ndid not do a good job, and we want to know what improvements we should\nmake.\n\n> \tOr is it smarter to just create a bare repository, clone some\n> \tcontent into it, and then push?\n\nIt depends on what you are trying to achieve by pushing into this\nrepository that is not bare, iow what this pushed-into repository is used\nfor.\n\nPushing into a repository is done for two reasons:\n\n - You push into repository A so that the development done in other\n   repositories B, C, D,... can all be collected, kept safe, and\n   transferred out to other repositories (iow, B, C, D uses A as a shared\n   meeting place).\n\n   This is the primary use case of \"push\", and because in repository A\n   there will not be any development of its own, people make A a (shared)\n   bare repository.\n\n - You do perform your own development in repository A, and you would want\n   to interact with other repositories B, C, D,..., by doing \"git pull B\"\n   etc., but for network configuration reasons, you can only make\n   connection to A from B, C, D..., and not in the other direction.  In\n   this case, because \"git pull B\" run on A is \"git fetch B\" followed by\n   \"git merge\", you substitute the first \"git fetch B\" part by running\n   \"git push A\" on B instead, because you can make connections from B to A\n   but not A to B.\n\n   In this case, you do not want your \"git push A\" run on B to overwrite\n   the branch that is checked out in A, and the above error is issued if\n   you attempted to do so.  This would show a proper arrangement for such\n   a \"push instead of fetch\":\n\n   http://git.wiki.kernel.org/index.php/GitFaq#push-is-reverse-of-fetch\n"},{"id":"136964","messageId":"E4235035-D3BD-44B9-9431-490400EE8A75@pelagicore.com","threadId":"23025","inReplyTo":"7v3a01v796.fsf@alter.siamese.dyndns.org","subject":"Re: git http-backend error message","fromName":"Jeremiah Foster","fromEmail":"jeremiah.foster@pelagicore.com","sentAt":"2010-03-16T17:10:25Z","receivedAt":"2010-03-16T17:10:25Z","isPatch":false,"sender":{"key":"jeremiah.foster@pelagicore.com","avatar":"https://gravatar.com/avatar/f107bff0d3617df3e171850d6ae81df4acb6767072fe7435a8c9f22b3824e5bd?d=mp&s=160"},"body":"\nOn Mar 15, 2010, at 6:12 PM, Junio C Hamano wrote:\n> Jeremiah Foster <jeremiah.foster@pelagicore.com> writes:\n> \n>> error: refusing to update checked out branch: refs/heads/master\n>> error: By default, updating the current branch in a non-bare repository\n>> error: is denied, because it will make the index and work tree inconsistent\n>> error: with what you pushed, and will require 'git reset --hard' to match\n>> error: the work tree to HEAD.\n>> error: \n>> error: You can set 'receive.denyCurrentBranch' configuration variable to\n>> error: 'ignore' or 'warn' in the remote repository to allow pushing into\n>> error: its current branch; however, this is not recommended unless you\n>> error: arranged to update its work tree to match what you pushed in some\n>> error: other way.\n>> error: \n>> error: To squelch this message and still keep the default behaviour, set\n>> error: 'receive.denyCurrentBranch' configuration variable to 'refuse'.\n>> \n>> \tI am unclear about my next move. Should I just set\n>> \treceive.denyCurrentBranch to 'warn' and then my commits locally\n>> \twill go back up to the server?\n> \n> After it becomes clear about your next move (people will try to help you\n> in this thread), please also tell us what information you found lacking in\n> the above advisory text that you had to ask this question.\n\nI didn't understand the dynamics of how changing the current branch would affect the index and work tree. I thought that when I pushed to the remote repo it was equivalent to doing a commit to the remote repo. In which case I assumed there would be no inconsistency with the index. Apparently I have an incomplete understanding of the index.\n\n>  The message is\n> trying to help you decide what your next move should be, but apparently\n> did not do a good job, and we want to know what improvements we should\n> make.\n\nI found the message helpful. If the suggestion of a bare repo was more explicit perhaps that would help. I am assuming of course that a bare repo was a suggestion.\n> \n>> \tOr is it smarter to just create a bare repository, clone some\n>> \tcontent into it, and then push?\n> \n> It depends on what you are trying to achieve by pushing into this\n> repository that is not bare, iow what this pushed-into repository is used\n> for.\n\nI was just testing out the mechanism of pushing over http, I had no important data in my repo.\n\n> \n> Pushing into a repository is done for two reasons:\n> \n> - You push into repository A so that the development done in other\n>   repositories B, C, D,... can all be collected, kept safe, and\n>   transferred out to other repositories (iow, B, C, D uses A as a shared\n>   meeting place).\n> \n>   This is the primary use case of \"push\", and because in repository A\n>   there will not be any development of its own, people make A a (shared)\n>   bare repository.\n\nThanks for this description. This is what I am hoping to achieve.\n\n> \n> - You do perform your own development in repository A, and you would want\n>   to interact with other repositories B, C, D,..., by doing \"git pull B\"\n>   etc., but for network configuration reasons, you can only make\n>   connection to A from B, C, D..., and not in the other direction.  In\n>   this case, because \"git pull B\" run on A is \"git fetch B\" followed by\n>   \"git merge\", you substitute the first \"git fetch B\" part by running\n>   \"git push A\" on B instead, because you can make connections from B to A\n>   but not A to B.\n> \n>   In this case, you do not want your \"git push A\" run on B to overwrite\n>   the branch that is checked out in A, and the above error is issued if\n>   you attempted to do so.  This would show a proper arrangement for such\n>   a \"push instead of fetch\":\n> \n>   http://git.wiki.kernel.org/index.php/GitFaq#push-is-reverse-of-fetch\n\nThanks very much for your detailed email - it is very helpful.\n\nRegards,\n\nJeremiah"},{"id":"138598","messageId":"hpctg0$416$1@dough.gmane.org","threadId":"23025","inReplyTo":"7v3a01v796.fsf@alter.siamese.dyndns.org","subject":"Re: git http-backend error message","fromName":"Scott R. Godin","fromEmail":"scottg.wp-hackers@mhg2.com","sentAt":"2010-04-05T14:52:47Z","receivedAt":"2010-04-05T14:52:47Z","isPatch":false,"sender":{"key":"scottg.wp-hackers@mhg2.com","avatar":"https://gravatar.com/avatar/766980733f46a32860153479ca94372e4fff5c4632e8586dbbfb143051d231ce?d=mp&s=160"},"body":"On 03/15/2010 01:12 PM, Junio C Hamano wrote:\n> Jeremiah Foster<jeremiah.foster@pelagicore.com>  writes:\n>> \tOr is it smarter to just create a bare repository, clone some\n>> \tcontent into it, and then push?\n>\n> It depends on what you are trying to achieve by pushing into this\n> repository that is not bare, iow what this pushed-into repository is used\n> for.\n>\n> Pushing into a repository is done for two reasons:\n>\n>   - You push into repository A so that the development done in other\n>     repositories B, C, D,... can all be collected, kept safe, and\n>     transferred out to other repositories (iow, B, C, D uses A as a shared\n>     meeting place).\n>\n>     This is the primary use case of \"push\", and because in repository A\n>     there will not be any development of its own, people make A a (shared)\n>     bare repository.\n>\n>   - You do perform your own development in repository A, and you would want\n>     to interact with other repositories B, C, D,..., by doing \"git pull B\"\n>     etc., but for network configuration reasons, you can only make\n>     connection to A from B, C, D..., and not in the other direction.  In\n>     this case, because \"git pull B\" run on A is \"git fetch B\" followed by\n>     \"git merge\", you substitute the first \"git fetch B\" part by running\n>     \"git push A\" on B instead, because you can make connections from B to A\n>     but not A to B.\n>\n>     In this case, you do not want your \"git push A\" run on B to overwrite\n>     the branch that is checked out in A, and the above error is issued if\n>     you attempted to do so.  This would show a proper arrangement for such\n>     a \"push instead of fetch\":\n>\n>     http://git.wiki.kernel.org/index.php/GitFaq#push-is-reverse-of-fetch\n\nThanks, this actually helped clear up a few things for me as well. I \nhaven't yet started working with remotes; mostly I've been using it to \ntake care of things on my end (this is a bit less problematic since I \nmostly use it for web devel tracking anyway) and then rsync to the \nwebserver. However, this is definitely going in my collection of notes \nand bookmarks for reference when I get to that point.\n\n\n-- \n(please respond to the list as opposed to my email box directly,\nunless you are supplying private information you don't want public\non the list)\n"}]}