pushing to a git repository does not work

Question

I am just starting out with GIT (i'm coming from cvs) and would like to set up something akin to cvs/svn with Git. I performed the following steps:

cd o:/repository
git init

cd <working directory>
git clone o:/repository

i now created a file called file.txt with some content doing a "git status" lists appropriate changes.

I then do

git add file.txt
git commit file.txt

and both seem to work fine.

When i do git push, i get the following error:

No refs in common and none specified; doing nothing.
Perhaps you should specify a branch such as 'master'.
fatal: The remote end hung up unexpectedly
error: failed to push some refs to 'o:/repository'

I tried doing a pull first, as well as specifying origin and master variations to the push command but none work.

Can someone please tell me what i am missing. I am running Windows 7 64 bit.

Ps. I also tried

git push origin master

and i get the following:

Counting objects: 3, done.
Writing objects: 100% (3/3), 251 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
remote: error: refusing to update checked out branch: refs/heads/master
remote: error: By default, updating the current branch in a non-bare repository
remote: error: is denied, because it will make the index and work tree inconsistent
remote: error: with what you pushed, and will require 'git reset --hard' to match
remote: error: the work tree to HEAD.
remote: error:
remote: error: You can set 'receive.denyCurrentBranch' configuration variable to
remote: error: 'ignore' or 'warn' in the remote repository to allow pushing into
remote: error: its current branch; however, this is not recommended unless you
remote: error: arranged to update its work tree to match what you pushed in some
remote: error: other way.
remote: error:
remote: error: To squelch this message and still keep the default behaviour, set
remote: error: 'receive.denyCurrentBranch' configuration variable to 'refuse'.
To O:/repository
 ! [remote rejected] master -> master (branch is currently checked out)
error: failed to push some refs to 'O:/repository'

Cha

Note that Git 2.3.0 (February 2015) allows for a more secure way to push to a non-bare repo: see my answer below. – Phillips

Answer 1

This happened to us a few weeks ago. It means that you have a working directory checked out in your origin repository and you cannot push to overwrite.

at the origin you need to bare the repository. I don't know of a way to do it with one command. What I did (at the origin repository)

> mv repository repository.old
> git clone --bare repository.old repository

I see that the origin in your case is the o:/repository. The origin, should not be a checked out working copy, so you can init a bare repository or copy as per above. To get the scenario you described to pass:

cd o:/repository
git init  --bare

cd <working directory>
git clone o:/repository

git push origin master

this should work just fine for you:

good reading: http://www.gitready.com/advanced/2009/02/01/push-to-only-bare-repositories.html

Julietajulietta

thanks, that worked, though with a minor modification, I had to call git push origin master. I was hoping i could just type git push and git would know where i checked out from/cloned from. I'm about to read the link you sent me, hopefully it will clear up what a --bare respository is and why i couldn't just call git push. – Cha

Oh just a small follow up question, are there no users defined in git like in cvs to specify who can read and write to the repository? – Cha

To the best of my understanding, you will need a 3rd party to do that for you. We run gitosis on a linux server for in-house development. Here is a post on how to set up on windows svr 2k8 shannoncornish.com/blog/2009/04/gitosis-windows-server-2008. But if I had it to do all over again, I would just use gitorious or github - that is what I do for my personal dev now. – Julietajulietta

slight back-peddling - theoretically, you could use file system permissions to manage user access. It might not be pretty, but could work. – Julietajulietta

@Cha (3 comments up): there are no users because of the distributed model git uses. Unlike CVS/SVN, where different people push changes to a common shared repository, in git, one person controls the "main"/"official" repository and pulls in changes from other developers. But you can sort of emulate the CVS/SVN model by effectively replacing that person with a computer program, which can handle access control - that's kind of what gitosis does, for example. – Columbary

Answer 2

For the first push you'll need something like

git push origin master

See also the push.default option option.

In any case, if you're later going to run into a problem of pushing to a non-bare repository, so you'll need to read about that too.

Restitution

yeah sorry, i should have been more explicit above. I tried this too and i get the error message i appended to the question above (didn't fit in a comment). – Cha

Like I said, you'll need a bare repo to do this sensibly. – Restitution

This happened to me when I did the checkout for the first time using BitBucket. Thank you very much! – Swamy

Answer 3

If you still want to push to a checked out branch of a remote non-bare repo, it is now possible (Git 2.3.0, February 2015), provided there is no modified files in the target working tree.

In that remote repo, do:

git config receive.denyCurrentBranch updateInstead

It is more secure than config receive.denyCurrentBranch=ignore: it will allow the push only if you are not overriding modification in progress.

See commit 1404bcb by Johannes Schindelin (dscho):

receive-pack: add another option for receive.denyCurrentBranch

When synchronizing between working directories, it can be handy to update the current branch via 'push' rather than 'pull', e.g. when pushing a fix from inside a VM, or when pushing a fix made on a user's machine (where the developer is not at liberty to install an ssh daemon let alone know the user's password).

The common workaround – pushing into a temporary branch and then merging on the other machine – is no longer necessary with this patch.

The new option is:

updateInstead

Update the working tree accordingly, but refuse to do so if there are any uncommitted changes.

---

As kd4ttc adds in the comments:

The idea here is for when you update a branch remotely you shouldn't normally be able to push it back.
Others who have pulled from the server and make changes won't know what changes happened while they were working independently.

However, it is just you that concern is not as great.
The clean way to do this is to pull from the repository and then make a branch: That you can edit all you want.

Some time in the future, you then log on the server and do a merge.

This option, updateInstead, is for when you have a situation where you want changes immediately in the files.

Phillips

For others, learning, like me, the idea here is if you update a branch remotely you shouldn't normally be able to push it back. Others who have pulled from the server and make changes won't know what changes happened while they were working independently. However, it is just you that concern is not as great. The clean way to do this is to pull from the repository and than make a branch. That you can edit all you want. Some time in the future you then log on the server and do a merge. This option, updateInstead, is for when you have a situation where you want changes immediately in the files. – Tab

@Tab Thank you for this comment: I have added it to the answer for more visibility. – Phillips

Answer 4

As the error message states, the branch you're trying to push to (master) is checked out in the origin repository. You could solve this by going to o:/repository and checking out a different branch.

Griffith