On Mar 15, 2010, at 6:12 PM, Junio C Hamano wrote: > Jeremiah Foster <jeremiah.foster@xxxxxxxxxxxxxx> writes: > >> 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. I 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. > 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. I 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. > >> 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. I was just testing out the mechanism of pushing over http, I had no important data in my repo. > > 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. Thanks for this description. This is what I am hoping to achieve. > > - 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 Thanks very much for your detailed email - it is very helpful. Regards, Jeremiah-- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html