75

I had a local git project that I wanted to add to gitolite. Apparently this is hard so I abandoned the idea. I created a new gitolite repo by adding it to gitolite-admin/conf/gitolite.conf and committing and pushing the changes. Then I cloned the new repo with git clone git-noah:project-name successfully. I then copied all files and folders except .git to the project-name folder. I did,

git add -A
git commit -a -m "Moved to new repo."
git push

I get this error:

warning: push.default is unset; its implicit value is changing in
Git 2.0 from 'matching' to 'simple'. To squelch this message
and maintain the current behavior after the default changes, use:

  git config --global push.default matching

To squelch this message and adopt the new behavior now, use:

  git config --global push.default simple

See 'git help config' and search for 'push.default' for further information.
(the 'simple' mode was introduced in Git 1.7.11. Use the similar mode
'current' instead of 'simple' if you sometimes use older versions of Git)

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 'git-noah:project-name'
Matthias Braun
  • 32,039
  • 22
  • 142
  • 171
Noah
  • 4,601
  • 9
  • 39
  • 52
  • You want to run either of the `git config` statements in the message. `git help config` will explain the differences between them for you. And you can read [this question](http://stackoverflow.com/questions/11872984/what-is-the-difference-between-git-push-default-current-and-push-default-upstrea) for more info. – Paul Hicks May 07 '14 at 21:30
  • possible duplicate of [Warning: push.default is unset; its implicit value is changing in Git 2.0](http://stackoverflow.com/questions/13148066/warning-push-default-is-unset-its-implicit-value-is-changing-in-git-2-0) – Paul Hicks May 07 '14 at 21:31
  • In fact, [this question](http://stackoverflow.com/questions/13148066/warning-push-default-is-unset-its-implicit-value-is-changing-in-git-2-0) seems to be the canonical reference. – Paul Hicks May 07 '14 at 21:31
  • 1
    possible duplicate of [Why can't I push to this bare repository?](http://stackoverflow.com/questions/6157730/why-cant-i-push-to-this-bare-repository) – CAMOBAP Sep 25 '14 at 12:44

7 Answers7

190

No "main" exists yet on the remote (origin) repository.

git push origin main

After this first push you can use the simpler

git push

Edit: With the recent trends my answer has been update to replace "master" with "main"

Oliver
  • 35,233
  • 12
  • 66
  • 78
  • 1
    @Enrico check the branch names you are pushing. With the recent trends the term "master" is being changed . – Oliver Sep 09 '20 at 13:42
  • 1
    @Oliver, yes you're right. Some prefer "master" as "main". – Tanzeel Nov 28 '20 at 17:45
  • 1
    @Tanzeel yes in 2020 "main" would probably the more appropriate choice. My original answer was written in 2014 predating the new branch naming discussions. – Oliver Nov 30 '20 at 08:17
  • 1
    Weird, main didn't work and gave me the refspec error... I had to change it to master. This is on a fresh github repo. – stackers Dec 03 '20 at 04:29
4

If you are receiving error:

No refs in common and none specified; doing nothing.
Perhaps you should specify a branch.

But not receiving error:

warning: push.default is unset

Make sure you have run git commit before attempting to run git push

pirateofebay
  • 930
  • 1
  • 10
  • 25
0

If you're using git to mirror then use this :

git config remote.backup.mirror true
Struggler
  • 672
  • 2
  • 9
  • 22
0

your master branch might be upstream and needs to be unset On branch master

Your branch is based on 'origin/master', but the upstream is gone. (use git branch --unset-upstream to fix)

Vijay Rajpurohit
  • 1,266
  • 2
  • 13
  • 25
Himan
  • 125
  • 3
  • 12
0

Taking up the comment of this user below the accepted answer.

I had the error in question when moving from an hg Mercurial repo to a GitLab repo using fast-export when the GitLab repository was already created some time ago by and still empty.

The reason for the error was that this empty frame of the new GitLab repo was already built with the setting that the main branch should be called "master". This is also what the message hints at: Perhaps you should specify a branch such as 'master'.

In your case, you likely hat a migration tool that switched the branch name to main by default. In my case, I had added the parameter -M -main to the fast-export command to change the name to the nowadays more common main - which then clashes with the needed master in the already setup GitLab repository.

Being in the git-repo folder, I ran (WRONG!):

/data/fast-export/hg-fast-export.sh -r /data/hg-repo -A /data/authors --force -M -main

Therefore, I went back to the start and tried it again without that -M -main: I deleted the .git folder in the git-repo folder, ran git init my_git_repo again, then ran the fast-export command just without -M -main. Then everything worked: I could git checkout HEAD, git remote add origin git@gitlab.com:my_project-url.git, git branch, git push -u origin --all and git push -u origin --tags.

questionto42
  • 7,175
  • 4
  • 57
  • 90
0

For me I had uncommitted files.

Ran git status

Added all files git add .

Ran git push

Then, git push origin main or master

Roger Perez
  • 2,807
  • 29
  • 31
-4

Your local and remote repositories do not share the same history, since you recreated the repo. Therefore, Git won't let you push this content.

If you are not afraid of losing the content that is on the remote repository, you can force push : git push -f.

Martin
  • 1,868
  • 1
  • 15
  • 20
  • They absolutely do share history! That is one of the most awesome things about git, it knows everything that happened in the remote repo because you cloned the whole thing. – Oliver Sep 09 '14 at 14:06