¿Qué es este mensaje de advertencia de Git cuando se envían cambios a un repositorio remoto?

7 minutos de lectura

¿Que es este mensaje de advertencia de Git cuando se
Coocoo4Cocoa

La descripción es un poco concisa. Simplemente agregué un archivo en mi rama maestra local y lo devolví a un repositorio remoto. ¿Alguna idea de por qué surge esto?

warning: updating the current branch
warning: Updating the currently checked out branch may cause confusion,
warning: as the index and work tree do not reflect changes that are in HEAD.
warning: As a result, you may see the changes you just pushed into it
warning: reverted when you run 'git diff' over there, and you may want
warning: to run 'git reset --hard' before starting to work to recover.
warning: 
warning: You can set 'receive.denyCurrentBranch' configuration variable to
warning: 'refuse' in the remote repository to forbid pushing into its
warning: current branch.
warning: To allow pushing into the current branch, you can set it to 'ignore';
warning: but this is not recommended unless you arranged to update its work
warning: tree to match what you pushed in some other way.
warning: 
warning: To squelch this message, you can set it to 'warn'.
warning: 
warning: Note that the default will change in a future version of git
warning: to refuse updating the current branch unless you have the
warning: configuration variable set to either 'ignore' or 'warn'.   

  • ¿Cuáles fueron los comandos exactos que usaste?

    –Esko Luontola

    29 de abril de 2009 a las 23:11

  • Empujar a un repositorio no desnudo ahora es más seguro con Git 2.3.0 (febrero de 2015), incluso si está empujando a una rama desprotegida: vea mi respuesta a continuación.

    – VoC

    1 de febrero de 2015 a las 11:22


  • posible duplicado de ¿Qué significa la advertencia de git “actualizando la rama actualmente desprotegida”?

    – Ciro Santilli Путлер Капут 六四事

    7 febrero 2015 a las 11:04

¿Que es este mensaje de advertencia de Git cuando se
VonC

Con Git 2.3.0 (después de febrero de 2015)

Si nadie está trabajando en ese repositorio remoto no desnudo, entonces debería ser posible enviar a una rama desprotegida.

Pero para estar más seguro en esa operación, ahora puede (con Git 2.3.0, febrero de 2015), hacer en ese repositorio remoto:

git config receive.denyCurrentBranch updateInstead

Es más seguro que config. receive.denyCurrentBranch=ignore: permitirá la inserción solo si no está anulando la modificación en curso.

Ver cometer 1404bcb por Johanes Schindelin (dscho):

receive-pack: añadir otra opción para receive.denyCurrentBranch

Al sincronizar entre directorios de trabajo, puede ser útil actualizar la rama actual a través de ‘push‘ en vez de ‘pull‘, por ejemplo, cuando se inserta una corrección desde el interior de una VM, o cuando se inserta una corrección realizada en la máquina de un usuario (donde el desarrollador no tiene la libertad de instalar un demonio ssh y mucho menos conocer la contraseña del usuario).

La solución alternativa común, empujar a una rama temporal y luego fusionarse en la otra máquina, ya no es necesaria con este parche.

La nueva opción es:

updateInstead

Actualice el árbol de trabajo en consecuencia, pero rechace hacerlo si hay cambios no confirmados.


los cometer 4d7a5ce agrega más pruebas y menciona:

El anterior solo prueba el caso en el que una ruta que se va a actualizar mediante push-to-deploy tiene un cambio incompatible en el árbol de trabajo del objetivo que ya se ha agregado al índice, pero la característica misma quiere requerir que el árbol de trabajo sea mucho más limpio que lo que se prueba.

Agregue un puñado de pruebas más para proteger la función de cambios futuros que, por error (desde el punto de vista del inventor de la función) relajen el requisito de limpieza, a saber:

  • Un cambio solo en el árbol de trabajo pero no en el índice sigue siendo un cambio que debe protegerse;
  • Es necesario proteger un archivo sin seguimiento en el árbol de trabajo que se sobrescribiría con una inserción para implementar;
  • Un cambio que hace que un archivo sea idéntico al que se está enviando sigue siendo un cambio que se debe proteger (es decir, el requisito de limpieza de la función es más estricto que el de pago).

Además, pruebe que un cambio de solo estadísticas en el árbol de trabajo no es una razón para rechazar una implementación forzada.

Con Git < 2.3.0 (antes de febrero de 2015)

El enfoque más común es crear un repositorio simple a partir del repositorio no simple y hacer que los repositorios git remotos/locales no solo apunten al repositorio simple recién creado.

  • Esto es extremadamente útil al emparejar o cambiar con frecuencia entre diferentes máquinas mientras se intenta mantener todo actualizado. También uso esto para mantener mi servidor de desarrollo actualizado (se reinicia automáticamente con los cambios de código) y al mismo tiempo puedo desarrollarlo cuando lo necesito. Esta es realmente la solución que le falta a la respuesta aceptada.

    – Thor84no

    11 de enero de 2016 a las 7:45


  • @Thor84no, de hecho. Y no olvides el enlace push-to-checkout de git 2.4: stackoverflow.com/a/34575157/6309. Nota: la respuesta aceptada era correcta en ese momento (tiene seis años)

    – VoC

    11 de enero de 2016 a las 7:48


  • Estoy usando la versión de Windows y Git 2.6.3.ventanas.1 y necesitaba eliminar el ‘=’, es decir git config receive.denyCurrentBranch updateInstead

    – jdpilgrim

    22 de enero de 2016 a las 11:56

  • updateInstead funcionó perfectamente para mí, gracias.

    – Hashim Aziz

    10 sep 2019 a las 16:59

  • realmente aprecio tu conocimiento

    – titoih

    15 de mayo de 2020 a las 14:28


¿Que es este mensaje de advertencia de Git cuando se
Jörg W. Mittag

En realidad, significa casi exactamente lo que dice: alguien está trabajando en el repositorio al que está ingresando, y ese alguien actualmente ha verificado exactamente la misma rama a la que está ingresando.

Esto es muy confuso, porque ahora piensan que han revisado la última versión de la rama, cuando, de hecho, acabas de actualizar la rama a una versión más nueva. Entonces, cuando ahora corren git commit, sus commit esencialmente revertirá todas las confirmaciones que acaba de enviar. Y cuando corren git diff verán lo contrario de todo lo que acabas de impulsar, aunque tal vez ni siquiera hayan cambiado nada.

Por esa razón, generalmente se considera una mala práctica enviar a un repositorio no vacío; solo debe enviar a repositorios desnudos, es decir, repositorios que no tienen una copia de trabajo adjunta. Como mínimo, debe asegurarse de no ingresar a la rama actualmente desprotegida, pero, en general, no debe simplemente insertar su código en el repositorio de otra persona, sino que debe pedirles que lo extraigan de usted.

En algunos casos especiales, como cuando está sirviendo un sitio web desde un repositorio de Git y desea actualizar el sitio web al enviarlo, en realidad tiene sentido enviar a la rama actualmente desprotegida, pero en ese caso debe asegurarse que tienes un gancho instalado que en realidad actualizaciones la copia de trabajo desprotegida, de lo contrario, su sitio web nunca se actualizará.

  • La forma en que manejo el problema del sitio web que menciona en su último párrafo es tener un repositorio central al que presiono, luego extraigo de eso al directorio de trabajo del sitio web. Este método requiere acceso de shell al servidor web, por supuesto, donde su método de enganche no necesariamente lo requiere.

    – Greg Hewgill

    30 de abril de 2009 a las 1:32

  • Jorge, gracias por la respuesta. El repositorio compartido no debería tener un directorio de trabajo, pero no lo inicié con –bare. Su uso es solo para compartir trabajo. Hay un área de “trabajo”, pero nadie la usa. ¿Debo reiniciar con bare?

    – Coocoo4Cocoa

    30 de abril de 2009 a las 22:49

  • Hmm, a menudo trabajo sin un repositorio centralizado. Trabajaré en código en mi computadora portátil y en una computadora de clúster con mi código de análisis. Ambos son mis propios repositorios y se parecen un poco al caso especial que describe.

    – David X

    19 mayo 2015 a las 19:24

1646956511 192 ¿Que es este mensaje de advertencia de Git cuando se
pluskid

Este es el mismo problema que Esta pregunta, la solución es usar git init --bare o git clone --bare.

  • Dice que incluso en el repositorio desnudo. (todo lo que hice fue actualizar el software git de la versión 1.5 a la 1.7)

    usuario208033

    13 de agosto de 2010 a las 21:24

  • Parece que la actualización de 1.5 a 1.7 activará este mensaje. Hice “mv reponame reponame.old; git clone –bare reponame.old reponame” para resolver esto. También tuve que usar “–shared=group” y corregir los permisos del grupo porque estoy ejecutando un repositorio compartido.

    – Sean Reifschneider

    22 de noviembre de 2010 a las 20:23

¿Ha sido útil esta solución?

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos y para mostrarte publicidad relacionada con sus preferencias en base a un perfil elaborado a partir de tus hábitos de navegación. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Configurar y más información
Privacidad