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

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:

se você não se importa com o histórico atual ou ausente, dê uma olhada nesta pergunta
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