git: actualizando la twig actual

Hay 2 repositorys git, A y B

En ambos solo hay una twig maestra, y ambos se revisan y trabajan en forma local.

Estoy presionando en la twig maestra de B desde A y recibo este post:

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'. 

Si trabajo en B's check out en la twig principal, ¿cómo puedo actualizarlo, entonces veo los cambios de A?

¿Qué pasa si también hay cambios en el pago local de Master en B que no están comprometidos?

Nota: Realmente no entiendo el post de git arriba. ¿"Causar confusión" significa que es malo y puede conducir a la pérdida de datos? O simplemente quiere decir que es una situación que no es fácil de manejar, pero como siempre puedo confiar en que todos mis cambios se mantienen de alguna manera y seré capaz de resolver conflictos si es necesario. ¿Qué significa "ver los cambios revertidos"? ¿Mena algunos cambios se pierden?

Para mí, como extranjero, este idioma no es muy claro.

Editar: acabo de agregar un file en A y lo coloqué en B. En BI recibo el estado de eliminación del file.

¿Cuál sería un flujo de trabajo simple para manejar la situación?

El tipo de confusión que se puede causar es así: supongamos que agrega muchos files en una confirmación en el master y lo envía al master de B. Luego, si cambia al tree de trabajo del repository B y ejecuta el git status , dirá que todos esos files que acaba de agregar han sido eliminados. Por supuesto, no se han eliminado; acaba de actualizar la twig actual y el tree de trabajo mientras no se haya tocado el índice. ¡Creo que eso count como confuso para muchas personas! (Esto es también lo que significa el post "ver los cambios revertidos": desde el estado de git, parece que ha revertido los commits que acaba de enviar, simplemente porque el tree de trabajo y el índice están ahora detrás de la twig).

En este caso, si está seguro de que el git status en B estuvo limpio antes de ingresar a su twig principal, puede restablecer el tree de trabajo y el índice para que coincida con la nueva position de la bifurcación con git reset --hard .

Sin embargo, si tuvo cambios no confirmados o no en B, esto de repente se vuelve doblemente confuso, ya que esos cambios reales serán difíciles de diferenciar de los "cambios" que resultaron del empuje: desentrañar aquellos que pueden ser muy difíciles.

Por lo tanto, si comprende lo que sucede y está contento de lidiar con esa situación, está bien. Personalmente, casi siempre trato de evitarlo por uno de:

  • Tirando de A a B en su lugar
  • Empujando hacia un repository vacío desde A, y luego tirando de B
  • Empujar directamente a otra reference en B desde A, como se explica en esta input de preguntas frecuentes de git , y la fusión de esa reference

Supongo que uno de los dos primeros es lo que quieres.

Recibe el post de error porque ingresa a un repository no vacío; ver las preguntas frecuentes de Git para algunos detalles. La solución corta es: no insert en un repository de git con un directory de trabajo; pero use un repository simple como intermediario.

Cuando ingresas en una twig, git actualiza la twig para reflejar el nuevo estado de la twig. Lo que no actualiza son el índice y el directory de trabajo (porque es posible que haya cambios allí y no pueda resolver los conflictos de todos modos, desde el control remoto).

En su ejemplo, esto significa lo siguiente:

  • Inicialmente, A y B tienen la misma twig maestra
  • Agregue un file F en la twig maestra de A, asigne este cambio y empújelo a la twig maestra de B
  • Ahora, la twig maestra de B (que está desprotegida en este momento) contiene F. Pero como git no tocó el directory de trabajo de B, F no existe allí
  • Por lo tanto, en B, git informa del file F como eliminado: está presente en el compromiso HEAD, pero no en el directory de trabajo.

En cuanto a su pregunta sobre la pérdida de datos: no pierde ningún dato con este empuje. Pero, si tuvo algún cambio en su directory de trabajo, podría ser difícil identificarlos, ya que ahora git diff muestra el diff frente al nuevo estado de la sucursal. Por lo tanto, algunos de los cambios son cambios reales, algunos de los cambios solo se muestran porque el process de pago nunca se actualizó a la versión actual.

Creo que el problema es que su repository remoto 'A' también está trabajando en la twig principal. Si introduce nuevos cambios en la misma twig, se confundirá. Tienes 2 opciones:

  • Vuelva a crear el repository A como 'desnudo': git init –bare

  • Verifique otra sucursal en A (git checkout another_branch) y luego intente volver a presionar desde B

machineB tiene una somebranch revisada, y está impulsando cambios en somebranch de la somebranch a la somebranch machineB , sin actualizar machineB working-copy o index . El tree que se verificó en la machineB aún estará en un punto antes de todos los cambios que realizó.

Ahora si vas a machineB y haces cambios y cometes sin hacer un git reset --hard primero, esos cambios formarán una nueva confirmación que no incluye todos los cambios que hiciste en machineA y somebranch divergirán. Si en lugar de comprometerse hiciera un git diff somebranch el diff debería mostrar todos los cambios que hizo en machineA está deshaciendo en machineB porque su checkout no está al machineB de la sucursal.