Rifiuto a distanza (aggiornamento superficiale non consentito) dopo aver modificato l'URL remoto di Git

164

Ho un progetto sotto il controllo della versione di Git che ho lavorato sia su un server che sul mio computer locale. Inizialmente avevo l'origine remota impostata come computer locale, ma ora vorrei cambiarlo in BitBucket.

Sul server ho usato il comando

git remote set-url origin bitbucket_address

Ma ora quando provo a spingere il mio progetto ricevo l'errore

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

Cosa sta causando questo e come posso risolverlo?

git

— rwolst
fonte

3

Come hai clonato la tua versione locale? git clone --depth?

— Sascha Wolf,

È stato un po 'di tempo fa e non ricordo. C'è un modo per scoprirlo?

— pubblicato l'

2

Dovrebbe esserci un file chiamato shallownella tua .gitcartella.

— Sascha Wolf,

Sì, posso vedere un shallowfile.

— pubblicato l'

Vedi stackoverflow.com/a/50996201 per una soluzione che scarta (o riscrive) la cronologia mancante

— caw

329

Sembra che tu abbia usato git clone --depth <number>per clonare la tua versione locale. Ciò si traduce in un clone superficiale . Una limitazione di un tale clone è che non è possibile spostarlo da un nuovo repository.

Ora hai due opzioni:

se non ti interessa la cronologia attuale o mancante, dai un'occhiata a questa domanda
se desideri conservare la cronologia completa, continua a leggere:

Quindi, vuoi conservare la tua storia, eh? Ciò significa che devi revocare il tuo repository. Per fare ciò dovrai aggiungere di nuovo il tuo vecchio telecomando.

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

Successivamente usiamo git fetchper recuperare la cronologia rimanente dal vecchio telecomando (come suggerito in questa risposta ).

git fetch --unshallow old

E ora dovresti essere in grado di spingere nel tuo nuovo repository remoto.

Nota : dopo aver riattivato il tuo clone puoi ovviamente rimuovere di nuovo il vecchio telecomando.

— Sascha Wolf
fonte

45

cosa succede se clonare un progetto kick-start e non voglio / ho bisogno dell'intera storia? c'è un modo per evitarlo?

— Itamar,

9

@itamar Questo sembra essere un buon esempio per una nuova domanda perfettamente valida. È possibile collegare a questa domanda per riferimento.

— Sascha Wolf,

14

Alla domanda come nuova domanda stackoverflow.com/questions/29748197/...

— Itamar

2

Si noti che git fetch --unshallowpuò essere necessario un refspec per annullare la revoca di un determinato ramo anziché dell'intero repository. Ad esempio:git fetch --unshallow origin refs/heads/mydeepbranch:refs/remotes/origin/mydeepbranch

— clacke,

5

Se si sta spingendo verso un repository un po 'indietro rispetto a qualsiasi repository da cui si è clonati, non creando un repository completamente nuovo, è sufficiente che il riferimento locale sia abbastanza profondo da contenere il riferimento remoto. Quindi, se avevi origin/master20 impegni in anticipo rispetto a te oldrepo/masterquando l'hai clone --depth 1edita e da allora hai fatto 17 commit locali, ti basterà fare git fetch --depth 37 origin refs/heads/master:refs/remotes/origin/master(scuse per qualsiasi errore off-by-one), e quindi puoi fare git push oldrepo mastersenza incidenti (potrebbe richiedere git 1.9.0 o successivo).

— clacke,

28

Nel caso in cui il tuo repository sia origin, e il repository originale è upstream:

git fetch --unshallow upstream

— Dorian
fonte

questo funziona per me e abbastanza facile quindi la risposta più votata.

— Maosheng Wang,

11

Un'altra opzione se si desidera mantenere il repository com'è con i nuovi commit aggiunti dopo il commit superficiale e iniziale è questo: modificare questo commit con un rebase interattivo .

Avvia un rebase interattivo incluso il primo commit (root) con
```
git rebase --interactive --root
```
Modificare il / picki commit iniziale / i in edite salvare e chiudere il file.

Se hai clonato il repository con una profondità maggiore di 1, potresti dover fare lo stesso per tutti questi commit. O, in alternativa, eseguire fixupper tutti questi durante il rebase interattivo.
Converti questo commit in un commit regolare, unshallow con
```
git commit --amend --no-edit
```
Questo cambierà anche l'ID commit e ti aggiungerà come coautore di questo commit iniziale.
Non dimenticare di finire il rebase
```
git rebase --continue
```

— Rene Hamburger
fonte

Grazie! Ha funzionato come un incantesimo, quando il repository originale è stato eliminato e ne hai solo una copia superficiale.

— Vitalii Dmitriev il

9

Se vuoi spingere il nuovo repository così com'è, puoi provare questo:

Innanzitutto rimuovi il old git folderdal tuo repository corrente,sudo rm -rf .git
Quindi inizializza nuovamente git git init
Quindi aggiungere il nuovo repository remoto git remote add your-new-repo
Quindi spingerlo.

— Akhter-UZ-Zaman
fonte

Ho trovato questa una soluzione migliore, dal momento che non richiede una spinta al vecchio. A volte questo può accadere con i piatti della caldaia.

— RNPD

Questa è sostanzialmente la risposta dalla domanda correlata che puoi trovare qui .

— Sascha Wolf,

@NachPD Non sono sicuro di cosa intendi quando dici che l'altra soluzione richiede "una spinta al vecchio". Intendi un recupero invece di una spinta? Perché non richiede una spinta.

— Sascha Wolf,

0

Se il recupero --unshallow non funziona. Devono esserci dei problemi con la tua filiale. Risolvilo con il seguente comando prima di spingerlo.

git filter-branch -- --all

Fallo solo con --unshallow non funziona poiché esiste un problema di SICUREZZA .

— Chayapol
fonte