I find that git can be a pain sometimes – but the benefit of using a distributed SCM and the way git handles files much outweigh some of the awkward usage of the tools. One thing I always get confused on is this error (mostly because I rarely make new repositories):
$ git push
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 '/my_source_repo'
When you first push to an empty repository, you have to do this:
$ git push origin master
Because you need to specify this one time so the remote repo has something in common. After doing that I got this message:
$ git push origin master
Counting objects: 163, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (116/116), done.
Writing objects: 100% (163/163), 219.29 KiB, done.
Total 163 (delta 23), reused 0 (delta 0)
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 /my_source_repo
! [remote rejected] master -> master (branch is currently checked out)
error: failed to push some refs to '/my_source_repo'
The problem here while somewhat convoluted is obvious: you cannot push to a non-bare repository. Theoretically you could blow away changes somewhere else and that is probably the #1 thing you don’t want a SCM tool to do. Of course in my situation I was using an empty repository. So what gives? You have to init the repo with the –bare keyword like so:
$ git init --bare my_source_repo
Then you’re checked in and back to coding!