Remoto rechazado (actualización superficial no permitida) después de cambiar la URL remota de Git

163

Tengo un proyecto bajo el control de versiones de Git que trabajé tanto en un servidor como en mi computadora local. Originalmente tenía el origen remoto configurado como mi computadora local, pero ahora me gustaría cambiarlo a BitBucket.

En el servidor usé el comando

git remote set-url origin bitbucket_address

Pero ahora, cuando intento impulsar mi proyecto, aparece el error

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

¿Qué está causando esto y cómo lo soluciono?

git

— rwolst
fuente

3

¿Cómo clonaste tu versión local? git clone --depth?

— Sascha Lobo

Fue hace un tiempo y no puedo recordar. ¿Hay una manera de averiguarlo?

— rwolst

2

Debe haber un archivo con nombre shallowen su .gitcarpeta.

— Sascha Lobo

Sí, puedo ver un shallowarchivo.

— rwolst

Visite stackoverflow.com/a/50996201 para obtener una solución que simplemente descarta (o reescribe) el historial que falta

— caw

328

Como parece que has usado git clone --depth <number>para clonar tu versión local. Esto da como resultado un clon poco profundo . Una limitación de tal clon es que no puede empujarlo a un nuevo repositorio.

Ahora tiene dos opciones:

Si no le importa su historial actual o faltante, eche un vistazo a esta pregunta
si desea mantener su historial completo, continúe leyendo:

Entonces, quieres mantener tu historia, ¿eh? Esto significa que tienes que deshacer tu repositorio. Para hacerlo, deberá agregar su control remoto anterior nuevamente.

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

Después de eso, usamos git fetchpara recuperar el historial restante del control remoto anterior (como se sugiere en esta respuesta ).

git fetch --unshallow old

Y ahora debería poder ingresar a su nuevo repositorio remoto.

Nota : Después de descifrar su clon, obviamente puede eliminar el control remoto anterior nuevamente.

— Sascha Wolf
fuente

45

¿Qué sucede si cloné un proyecto inicial y no quiero / necesito toda la historia? ¿Hay alguna forma de evitarlo?

— itamar

9

@itamar Esto parece ser un buen ejemplo para una nueva pregunta perfectamente válida. Puede vincular a esta pregunta como referencia.

— Sascha Wolf

14

Preguntado como nueva pregunta stackoverflow.com/questions/29748197/…

— itamar

2

Tenga en cuenta que git fetch --unshallowpuede tomar una especificación de referencia solo para anular una determinada rama en lugar de todo el repositorio. Por ejemplo:git fetch --unshallow origin refs/heads/mydeepbranch:refs/remotes/origin/mydeepbranch

— clacke

55

Si está presionando a un repositorio que está un poco detrás del repositorio desde el que clonó, sin crear un repositorio completamente nuevo, es suficiente que su referencia local sea lo suficientemente profunda como para contener la referencia remota. Entonces, si origin/mastertenía 20 confirmaciones antes de oldrepo/mastercuando lo clone --depth 1editó, y ha realizado 17 confirmaciones locales desde entonces, es suficiente para que lo haga git fetch --depth 37 origin refs/heads/master:refs/remotes/origin/master(disculpas por cualquier error de uno por uno), y luego puede hacerlo git push oldrepo mastersin incidentes (puede requerir git 1.9.0 o más reciente).

— clacke

27

En caso de que su repositorio sea origin, y el repositorio original sea upstream:

git fetch --unshallow upstream

— dorio
fuente

esto funciona para mí, y bastante fácil, entonces la respuesta más votada.

— Maosheng Wang

11

Otra opción si desea mantener el repositorio tal como está con las nuevas confirmaciones que ha agregado desde la confirmación inicial superficial es la siguiente: modifique esta confirmación con un rebase interactivo .

Inicie un rebase interactivo que incluya la primera confirmación (raíz) con
```
git rebase --interactive --root
```
Cambie la pickde las confirmaciones iniciales a edity guarde y cierre el archivo.

Si ha clonado el repositorio con una profundidad mayor que 1, es posible que deba hacer lo mismo para todas esas confirmaciones. O, alternativamente, ejecute fixuppara todos estos durante el rebase interactivo.
Convierta esta confirmación en una confirmación regular, no profunda
```
git commit --amend --no-edit
```
Esto también cambiará la ID de confirmación y lo agregará como coautor a esta confirmación inicial.
No olvides terminar tu rebase
```
git rebase --continue
```

— Rene Hamburger
fuente

¡Gracias! Funcionó de maravilla, cuando se eliminó el repositorio original y solo tiene una copia superficial del mismo.

— Vitalii Dmitriev

9

Si desea impulsar el nuevo repositorio tal como está, puede intentar esto:

Primero elimine el old git folderde su repositorio actual,sudo rm -rf .git
Luego inicialice el git nuevamente git init
Luego agregue el nuevo repositorio remoto git remote add your-new-repo
Entonces empujarlo.

— Akhter-uz-zaman
fuente

Encontré esta una mejor solución, ya que no requiere un empujón a lo viejo. A veces esto podría suceder con repeticiones.

— rnpd

Esta es básicamente la respuesta de la pregunta relacionada que puedes encontrar aquí .

— Sascha Wolf

@NachPD No estoy seguro de lo que quieres decir, cuando dices que la otra solución requiere "un empujón a lo viejo". ¿Te refieres a una búsqueda en lugar de un empujón? Porque no requiere un empujón.

— Sascha Wolf

0

Si va a buscar --unshallow no funciona. Debe haber algunos problemas con su sucursal. Corríjalo con el siguiente comando antes de presionarlo.

git filter-branch -- --all

Haga esto solo con --unshallow no funciona ya que existe una preocupación de SEGURIDAD .

— Chayapol
fuente