Re: git http-backend error message
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Mar 15, 2010, 17:12 UTC
- Message-ID
- <7v3a01v796.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <A55E5483-425E-4303-87F2-FABC46F6BFE5@pelagicore.com>
Jeremiah Foster <jeremiah.foster@pelagicore.com> writes:
Show 18 quoted lines
> error: refusing to update checked out branch: refs/heads/master > error: By default, updating the current branch in a non-bare repository > error: is denied, because it will make the index and work tree inconsistent > error: with what you pushed, and will require 'git reset --hard' to match > error: the work tree to HEAD. > error: > error: You can set 'receive.denyCurrentBranch' configuration variable to > error: 'ignore' or 'warn' in the remote repository to allow pushing into > error: its current branch; however, this is not recommended unless you > error: arranged to update its work tree to match what you pushed in some > error: other way. > error: > error: To squelch this message and still keep the default behaviour, set > error: 'receive.denyCurrentBranch' configuration variable to 'refuse'. > > I 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?
After it becomes clear about your next move (people will try to help you in this thread), please also tell us what information you found lacking in the above advisory text that you had to ask this question. The message is trying to help you decide what your next move should be, but apparently did not do a good job, and we want to know what improvements we should make.
> Or is it smarter to just create a bare repository, clone some > content into it, and then push?
It depends on what you are trying to achieve by pushing into this repository that is not bare, iow what this pushed-into repository is used for.
Pushing into a repository is done for two reasons:
- You push into repository A so that the development done in other repositories B, C, D,... can all be collected, kept safe, and transferred out to other repositories (iow, B, C, D uses A as a shared meeting place).
This is the primary use case of "push", and because in repository A there will not be any development of its own, people make A a (shared) bare repository.
- You do perform your own development in repository A, and you would want to interact with other repositories B, C, D,..., by doing "git pull B" etc., but for network configuration reasons, you can only make connection to A from B, C, D..., and not in the other direction. In this case, because "git pull B" run on A is "git fetch B" followed by "git merge", you substitute the first "git fetch B" part by running "git push A" on B instead, because you can make connections from B to A but not A to B.
In this case, you do not want your "git push A" run on B to overwrite the branch that is checked out in A, and the above error is issued if you attempted to do so. This would show a proper arrangement for such a "push instead of fetch":
http://git.wiki.kernel.org/index.php/GitFaq#push-is-reverse-of-fetch