286

Can you explain what is wrong with this workflow?

$ git init --bare bare
Initialized empty Git repository in /work/fun/git_experiments/bare/
$ git clone bare alice
Cloning into alice...
done.
warning: You appear to have cloned an empty repository.
$ cd alice/
$ touch a
$ git add a
$ git commit -m "Added a"
[master (root-commit) 70d52d4] Added a
 0 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 a
$ 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 '/work/fun/git_experiments/bare'

Doesn't git push always push to the repository I cloned from?

ripper234
  • 222,824
  • 274
  • 634
  • 905
  • Shouldn't you specify branch to push? – Rekin May 27 '11 at 21:14
  • 3
    not after a clone!!! after the problem is fixed, it works great and no need to specify the branch...just on this first checkout of an empty repository does this occur which is VERY VERY annoying...they should fix this issue. – Dean Hiller May 23 '12 at 16:49
  • Hope this post would be useful to somebody when trying to do above- http://samranga.blogspot.com/2015/07/create-git-bitbucket-repository-from.html?view=sidebar The error in the question can be popped even when tried to Create a git BitBucket repository from an already locally existing project – Samitha Chathuranga Jul 02 '15 at 13:08

6 Answers6

487

Yes, the problem is that there are no commits in "bare". This is a problem with the first commit only, if you create the repos in the order (bare,alice). Try doing:

git push --set-upstream origin master

This would only be required the first time. Afterwards it should work normally.

As Chris Johnsen pointed out, you would not have this problem if your push.default was customized. I like upstream/tracking.

ahsteele
  • 26,243
  • 28
  • 134
  • 248
Seth Robertson
  • 30,608
  • 7
  • 64
  • 57
  • 1
    I'm doing `sudo apt-get upgrade git-core` and `sudo apt-get upgrade git` and it think no update is necessary. `git --version` returns 1.7.3.1. Any idea what's missing? I admit currently `apt-get update` doesn't work for me, but it did not too long ago. – ripper234 May 27 '11 at 21:35
  • 1
    @ripper234: The current version of git is 1.7.5.3 You can either live with the inconvenience, use a different workflow, or install the latest git manually w/o debian/ubuntu packaging. – Seth Robertson May 27 '11 at 21:37
  • Ah right, I forget that software take some time before it gets packaged. I'm a linux noob, coming from Windows, and used to click-here-to-install-the-newest-version. – ripper234 May 27 '11 at 21:47
  • 9
    Regarding “Recent version don't have this problem”: Even in recent versions, the default for pushes does not seem to have changed from `matching`; maybe you have `push.default` set to `upstream`/`tracking` (or `current`) in your `~/.gitconfig`? – Chris Johnsen May 28 '11 at 06:11
  • @Chris Johnsen: Good catch. I always forget that the default isn't tracking since I have had that set ever since I started using git several years ago and it seems so sane. – Seth Robertson May 28 '11 at 20:56
  • @SethRobertson When I run your command, I get the following error: error: src refspec master does not match any. error: failed to push some refs to 'git@bitbucket.org:username/myproject.git' – IgorGanapolsky Feb 21 '14 at 15:23
  • 4
    Try `git push origin master:master` to make it explicit. If that doesn't work, check to see what branch you are on: `git branch` perhaps you have not made the first commit or you made that commit on a branch other than master. – Seth Robertson Feb 22 '14 at 16:37
  • @Igor Ganapolsky: Previous comment was directed at you. This present just for notification purposes (will edits cause notifications?) – Seth Robertson Feb 22 '14 at 16:43
  • In later versions of Git, this syntax is a little more terse: `git push -u origin master`. It pushes "master" to origin and sets up remote tracking. – Greg Burghardt Dec 12 '14 at 19:43
  • Hope this post would be useful to somebody- http://samranga.blogspot.com/2015/07/create-git-bitbucket-repository-from.html?view=sidebar The error in the question can be popped even when tried to Create a git BitBucket repository from an already locally existing project – Samitha Chathuranga Jul 02 '15 at 13:07
  • This doesn't work. "error: src refspec origin does not match any." – pabrams Aug 16 '18 at 12:43
  • @pabrams Did you see the dup comment above and my reply giving a more specific command that seems to be sometimes necessary (depending on your push.default setting). – Seth Robertson Aug 17 '18 at 13:47
42

If you:

 git push origin master

it will push to the bare repo.

It sounds like your alice repo isn't tracking correctly.

cat .git/config

This will show the default remote and branch.

If you

 git push -u origin master

You should start tracking that remote and branch. I'm not sure if that option has always been in git.

Gn13l
  • 353
  • 2
  • 12
serby
  • 4,186
  • 2
  • 24
  • 25
32

This related question's answer provided the solution for me... it was just a dumb mistake:

Remember to commit first!

https://stackoverflow.com/a/7572252

If you have not yet committed to your local repo, there is nothing to push, but the Git error message you get back doesn't help you too much.

Community
  • 1
  • 1
phpguru
  • 2,351
  • 2
  • 23
  • 33
19
git push --all

is the canonical way to push everything to a new bare repository.

Another way to do the same thing is to create your new, non-bare repository and then make a bare clone with

git clone --bare

then use

git remote add origin <new-remote-repo>

in the original (non-bare) repository.

ebneter
  • 20,795
  • 9
  • 30
  • 30
  • ...so you downvoted the answer? It _is_ the standard way to push everything to a new, bare repository. If it didn't work for you, there is some other issue. – ebneter May 28 '11 at 07:59
  • You're right, I probably shouldn't have, I know you were just trying to help. If you edit it I'll undo my downvote. – ripper234 May 28 '11 at 11:14
  • Thanks, edited it with another way to accomplish the same task. – ebneter May 29 '11 at 04:03
  • Your answer helped me thanks ;) But at the end of the command, the path must be present like this: `git push --all ../test_repo` the repo's URL at the end of the command ;) – Metafaniel Aug 29 '12 at 21:47
  • @Metafaniel That depends on how you set it up. If your local repo already has the remote properly configured, "git push --all" should work as is. – ebneter Aug 29 '12 at 23:55
7

Try this in your alice repository (before pushing):

git config push.default tracking

Or, configure it as the default for your user with git config --global ….

git push does default to the origin repository (which is normally the repository from which you cloned the current repository), but it does not default to pushing the current branch—it defaults to pushing only branches that exist in both the source repository and the destination repository.

The push.default configuration variable (see git-config(1)) controls what git push will push when it is not given any “refspec” arguments (i.e. something after a repository name). The default value gives the behavior described above.

Here are possible values for push.default:

  • nothing
    This forces you to supply a “refspec”.

  • matching (the default)
    This pushes all branches that exist in both the source repository and the destination repository.
    This is completely independent of the branch that is currently checked out.

  • upstream or tracking
    (Both values mean the same thing. The later was deprecated to avoid confusion with “remote-tracking” branches. The former was introduced in 1.7.4.2, so you will have to use the latter if you are using Git 1.7.3.1.)
    These push the current branch to the branch specified by its “upstream” configuration.

  • current
    This pushes the current branch to the branch of the same name at the destination repository.

    These last two end up being the same for common cases (e.g. working on local master which uses origin/master as its upstream), but they are different when the local branch has a different name from its “upstream” branch:

    git checkout master
# hack, commit, hack, commit

# bug report comes in, we want a fix on master without the above commits

git checkout -b quickfix origin/master  # "upstream" is master on origin
# fix, commit
git push

    With push.default equal to upstream (or tracking), the push would go to origin’s master branch. When it is equal to current, the push would go to origin’s quickfix branch.

The matching setting will update bare’s master in your scenario once it has been established. To establish it, you could use git push origin master once.

However, the upstream setting (or maybe current) seems like it might be a better match for what you expect to happen, so you might want to try it:

# try it once (in Git 1.7.2 and later)
git -c push.default=upstream push

# configure it for only this repository
git config push.default upstream

# configure it for all repositories that do not override it themselves
git config --global push.default upstream

(Again, if you are still using a Git before 1.7.4.2, you will need to use tracking instead of upstream).

Chris Johnsen
  • 214,407
  • 26
  • 209
  • 186
1

I use SourceTree git client, and I see that their initial commit/push command is:

git -c diff.mnemonicprefix=false -c core.quotepath=false push -v --tags --set-upstream origin master:master
IgorGanapolsky
  • 26,189
  • 23
  • 116
  • 147