Re: git http-backend error message
On Mar 15, 2010, at 6:12 PM, Junio C Hamano wrote:
Show 24 quoted lines
> Jeremiah Foster <jeremiah.foster@pelagicore.com> 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.
Show 7 quoted lines
>
>> 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.
Show 11 quoted lines
>
> 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.
Show 16 quoted lines
>
> - 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
Jeremiah Foster <jeremiah.foster@pelagicore.com>