196

I have a project under Git version control that I worked on both a server and my local computer. I originally had the remote origin set as my local computer but I would now like to change that to BitBucket.

On the server I used the command

git remote set-url origin bitbucket_address

But now when I try to push my project I get the error

 ! [remote rejected] master -> master (shallow update not allowed)

What is causing this and how do I fix it?

rwolst
  • 10,604
  • 13
  • 44
  • 67

6 Answers6

385

As it seems you have used git clone --depth <number> to clone your local version. This results in a shallow clone. One limitation of such a clone is that you can't push from it into a new repository.

You now have two options:

  1. if you don't care about you're current or missing history, take a look at this question
  2. if you want to keep your full history, then continue reading:

So, you want to keep your history, eh? This means that you have to unshallow your repository. To do so you will need to add your old remote again.

git remote add old <path-to-old-remote>

After that we use git fetch to fetch the remaining history from the old remote (as suggested in this answer).

git fetch --unshallow old

And now you should be able to push into your new remote repository.

Note: After unshallowing your clone you can obviously remove the old remote again.

Sascha Wolf
  • 15,124
  • 4
  • 43
  • 71
  • 53
    what if i cloned a kick-start project and i don't want/need the whole history? is there a way to avoid it? – itamar Mar 25 '15 at 16:43
  • 10
    @itamar This seems to be a good example for a perfectly valid new question. You could link to this question for reference. – Sascha Wolf Apr 20 '15 at 06:36
  • 17
    Asked as new question http://stackoverflow.com/questions/29748197/how-to-clone-seed-kick-start-project-without-the-whole-history – itamar Apr 20 '15 at 12:41
  • 4
    Note that `git fetch --unshallow` can take a refspec to only unshallow a certain branch rather than the whole repo. E.g.: `git fetch --unshallow origin refs/heads/mydeepbranch:refs/remotes/origin/mydeepbranch` – clacke Oct 31 '15 at 14:07
  • 5
    If you are pushing to a repo that is a bit behind whatever repo you cloned from, not creating an all-new repo, it is enough that your local reference is deep enough to contain the remote reference. So if your `origin/master` was 20 commits ahead of your `oldrepo/master` when you `clone --depth 1`'ed it, and you have made 17 local commits since, it is enough for you to do `git fetch --depth 37 origin refs/heads/master:refs/remotes/origin/master` (apologies for any off-by-one error), and then you can do `git push oldrepo master` without incident (may require git 1.9.0 or newer). – clacke Oct 31 '15 at 14:13
  • 2
    @itamar delete /.git/ (& reference in package.json) and git init – user36388 Jun 13 '17 at 09:50
37

In case your repo is origin, and the original repo is upstream:

git fetch --unshallow upstream
Dorian
  • 19,009
  • 8
  • 108
  • 111
14

Another option if you want to keep the repo as is with the new commits you have added since the shallow, initial commit is this: Amend this commit with an interactive rebase.

  • Start an interactive rebase including the first (root) commit with

    git rebase --interactive --root

  • Change the pick of the initial commit(s) to edit and save & close the file.

    If you've cloned the repo with greater depth than 1, you may need to do the same for all of those commits. Or, alternatively, execute fixup for all of these during the interactive rebase.

  • Convert this commit to a regular, unshallow commit with

    git commit --amend --no-edit

    This will also change the commit ID and add you as co-author to this initial commit.

  • Don't forget to finish your rebase

    git rebase --continue
Jayen
  • 4,499
  • 2
  • 34
  • 59
Rene Hamburger
  • 1,588
  • 11
  • 15
11

If you want to push the new repo as it is, you can try this:

  • First remove the old git folder from your current repo,sudo rm -rf .git
  • Then initialize the git again git init
  • Then add the new remote repo git remote add your-new-repo
  • Then Push it.
Akhter-uz-zaman
  • 177
  • 2
  • 7
  • I found this a better solution, since it doesn't require a push to the old. Sometimes this could happen with boilerplates. – rnpd Jul 02 '18 at 15:57
  • This is basically the answer from the [related question which you can find here](http://stackoverflow.com/questions/29748197/how-to-clone-seed-kick-start-project-without-the-whole-history). – Sascha Wolf Aug 10 '18 at 10:51
  • 1
    @NachPD I'm not sure what you mean, when you say that the other solution requires "a push to the old". Do you mean a fetch instead of a push? Because it does not require a push. – Sascha Wolf Aug 10 '18 at 10:51
1

If fetching --unshallow doesn't work. There must be some problems with your branch. Fix it with the following command before pushing it.

git filter-branch -- --all

Do this only with --unshallow doesn't work since there's a SAFETY concern.

Chayapol
  • 2,519
  • 1
  • 15
  • 7
0

Based on the most upvoted answer, I created an alias to automate things:

Add to your .gitconfig:

[alias]
    unshallow = !"git fetch --unshallow \"${1:-origin}\" # Unshallow from remote $1 (defaults to origin)"

Usage:

  • git unshallow # unshallow current branch based on the origin remote
  • git unshallow other-remote # unshallow current branch from remote other-remote
Tom Hale
  • 25,410
  • 16
  • 132
  • 172