git http-backend error message

git http-backend error message

[Jeremiah Foster]

Hello,

	I'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. 

	What 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;

	'git push origin master' 

	I get this error:

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? 
	Or is it smarter to just create a bare repository, clone some content into it, and then push?

Thanks,

	Jeremiah

Re: git http-backend error message

[Junio C Hamano]

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.  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

Re: git http-backend error message

[Jeremiah Foster]

On Mar 15, 2010, at 6:12 PM, Junio C Hamano wrote:
> 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.
> 
>> 	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

Re: git http-backend error message

[Scott R. Godin]

On 03/15/2010 01:12 PM, Junio C Hamano wrote:
> Jeremiah Foster<jeremiah.foster@pelagicore.com>  writes:
>> 	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

Thanks, this actually helped clear up a few things for me as well. I 
haven't yet started working with remotes; mostly I've been using it to 
take care of things on my end (this is a bit less problematic since I 
mostly use it for web devel tracking anyway) and then rsync to the 
webserver. However, this is definitely going in my collection of notes 
and bookmarks for reference when I get to that point.


-- 
(please respond to the list as opposed to my email box directly,
unless you are supplying private information you don't want public
on the list)