Remoto rejeitado (atualização superficial não permitida) após alterar o URL remoto do Git

163

Eu tenho um projeto sob controle de versão do Git em que trabalhei em um servidor e no meu computador local. Originalmente, eu tinha a origem remota definida como meu computador local, mas agora gostaria de mudar isso para BitBucket.

No servidor eu usei o comando

git remote set-url origin bitbucket_address

Mas agora, quando tento empurrar meu projeto, recebo o erro

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

O que está causando isso e como corrigi-lo?

git rwolst
fonte
3
Como você clonou sua versão local? git clone --depth?
Sascha Lobo
Foi há um tempo atrás e não me lembro. Tem alguma maneira de descobrir?
rwolst
2
Deve haver um arquivo nomeado shallowna sua .gitpasta.
Sascha Wolf
Sim, eu posso ver um shallowarquivo.
rwolst
Veja stackoverflow.com/a/50996201 por uma solução que devoluções apenas (ou reescritas) os desaparecidos história
caw

Respostas:

328

Como parece que você costumava git clone --depth <number>clonar sua versão local. Isso resulta em um clone superficial . Uma limitação desse clone é que você não pode enviá-lo para um novo repositório.

Agora você tem duas opções:

  1. se você não se importa com o histórico atual ou ausente, dê uma olhada nesta pergunta
  2. se você deseja manter seu histórico completo, continue lendo:

Então, você quer manter sua história, não é? Isso significa que você precisa desarmar seu repositório. Para fazer isso, você precisará adicionar seu controle remoto antigo novamente.

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

Depois disso, git fetchcostumamos buscar o histórico restante do controle remoto antigo (como sugerido nesta resposta ).

git fetch --unshallow old

E agora você deve poder entrar no seu novo repositório remoto.

Nota : Depois de remover o clone, você obviamente poderá remover o controle remoto antigo novamente.

Sascha Wolf
fonte
45
e se eu clonar um projeto de arranque e não quiser / precisar de toda a história? existe uma maneira de evitá-lo?
Itamar # 25/15
9
@itamar Este parece ser um bom exemplo para uma nova pergunta perfeitamente válida. Você pode vincular a esta pergunta para referência.
Sascha Lobo
14
Perguntado como nova pergunta stackoverflow.com/questions/29748197/…
itamar 20/04/2015
2
Observe que git fetch --unshallowpode ser necessário um refspec para desalocar apenas um determinado ramo, em vez de todo o repositório Por exemplo:git fetch --unshallow origin refs/heads/mydeepbranch:refs/remotes/origin/mydeepbranch
clacke 31/10/2015
5
Se você está empurrando para um repositório que está um pouco atrás do repositório do qual você clonou, sem criar um repositório totalmente novo, basta que sua referência local seja profunda o suficiente para conter a referência remota. Portanto, se você origin/mastertinha 20 commits à frente do seu oldrepo/masterquando você clone --depth 1o executou, e você fez 17 commits locais desde então, basta fazer isso git fetch --depth 37 origin refs/heads/master:refs/remotes/origin/master(desculpas por qualquer erro isolado por um) e, em seguida, você pode fazê-lo git push oldrepo mastersem incidentes (pode exigir o git 1.9.0 ou mais recente).
Clacke
27

Caso o seu repo seja origine o repo original seja upstream:

git fetch --unshallow upstream
Dorian
fonte
isso funciona para mim, e muito fácil, então a resposta mais votada.
Maosheng Wang
11

Outra opção, se você deseja manter o repositório como está com os novos commits que você adicionou desde a submissão inicial rasa, é a seguinte: altere esse commit com uma nova reorganização interativa .

  • Inicie uma rebase interativa, incluindo a primeira confirmação (raiz) com

    git rebase --interactive --root

  • Altere o pick(s) commit (s) inicial (is) edite salve e feche o arquivo.

    Se você clonou o repositório com profundidade maior que 1, pode ser necessário fazer o mesmo para todos esses commits. Ou, alternativamente, execute fixuppara todos eles durante o rebase interativo.

  • Converta esse commit em um commit regular e não raso com

    git commit --amend --no-edit

    Isso também mudará o ID da confirmação e o adicionará como co-autor a esta confirmação inicial.

  • Não se esqueça de finalizar sua rebase

    git rebase --continue
Rene Hamburger
fonte
Obrigado! Funcionou como um encanto, quando o repositório original foi excluído e você tem apenas uma cópia superficial dele.
Vitalii Dmitriev
9

Se você deseja enviar por push o novo repositório como está, tente o seguinte:

  • Primeiro remova o old git folderdo seu repo atual,sudo rm -rf .git
  • Em seguida, inicialize o git novamente git init
  • Em seguida, adicione o novo repositório remoto git remote add your-new-repo
  • Então empurre.
Akhter-uz-zaman
fonte
Achei isso uma solução melhor, pois não requer um empurrão para o antigo. Às vezes isso pode acontecer com clichês.
Rnpd 02/07
Esta é basicamente a resposta da pergunta relacionada que você pode encontrar aqui .
Sascha Lobo
@NachPD Não sei ao certo o que você quer dizer quando diz que a outra solução exige "um empurrão para o antigo". Você quer dizer uma busca em vez de um empurrão? Porque não requer um empurrão.
Sascha Lobo
0

Se buscar --unshallow não funcionar. Deve haver alguns problemas com sua filial. Corrija-o com o seguinte comando antes de pressioná-lo.

git filter-branch -- --all

Faça isso apenas com --unshallow não funciona, pois há uma preocupação com SEGURANÇA .

Chayapol
fonte