remove - Git-Diferencia entre ''asumir-sin cambios'' y ''saltar-trabajo''

git push tag

Question

Tengo cambios locales en un archivo que no quiero enviar a mi repositorio. Es un archivo de configuración para compilar la aplicación en un servidor, pero quiero compilar localmente con diferentes configuraciones. Naturalmente, el archivo siempre aparece cuando hago ''git status'' como algo que se va a organizar. Me gustaría ocultar este cambio en particular y no cometerlo. No haré ningún otro cambio en el archivo.

Después de investigar un poco, veo 2 opciones: ''asumir-sin cambios'' y ''saltar-trabajar-árbol''. Una pregunta anterior here habla de ellos, pero realmente no explica sus diferencias. Mi pregunta es la siguiente: ¿en qué se diferencian los dos comandos? ¿Por qué alguien usaría uno u otro?

Answer 1

Nota: fallengamer hizo algunas pruebas en 2011 (por lo que pueden estar desactualizadas), y aquí están sus http://fallengamer.livejournal.com/93321.html :

Operaciones

• El archivo se modifica tanto en el repositorio local como en el sentido ascendente
  git pull :
  Git conserva los cambios locales de todos modos.
  Por lo tanto, no perdería accidentalmente ningún dato que haya marcado con ninguna de las banderas.
  • Archivo con indicador de assume-unchanged : Git no sobrescribiría el archivo local. En su lugar, daría lugar a conflictos y consejos sobre cómo resolverlos.
  • Archivo con el indicador skip-worktree : Git no sobrescribiría el archivo local. En su lugar, daría lugar a conflictos y consejos sobre cómo resolverlos.

.

• El archivo se modifica tanto en el repositorio local como en el ascendente, intentando extraerlo de todos modos
  git stash
git pull
  El uso de skip-worktree da skip-worktree resultado un trabajo manual adicional, pero al menos no perdería ningún dato si tuviera cambios locales.
  • Archivo con indicador de assume-unchanged : descarta todos los cambios locales sin posibilidad de restaurarlos. El efecto es como '' git reset --hard ''. La llamada '' git pull '' tendrá éxito
  • Archivo con el indicador skip-worktree : Stash no funcionaría en archivos skip-worktree . '' git pull '' fallará con el mismo error que el anterior. El desarrollador se ve obligado a restablecer manualmente el indicador skip-worktree para poder ocultar y completar el pull falla.

.

• No hay cambios locales, el archivo ascendente cambió
  git pull
  Ambas banderas no evitarían que obtuvieras cambios anteriores. Git detecta que rompiste la promesa de assume-unchanged y elige reflejar la realidad restableciendo la bandera.
  • Archivo con indicador de assume-unchanged : el contenido se actualiza, el indicador se pierde.
    '' git ls-files -v '' mostraría que la bandera se modifica a H (desde h ).
  • Archivo con el indicador skip-worktree : el contenido se actualiza, el indicador se conserva.
    '' git ls-files -v '' mostraría la misma bandera S que antes de la pull .

.

• Con el archivo local cambiado
  git reset --hard
  Git no toca el archivo skip-worktree y refleja la realidad (el archivo que se prometió que no se modificará en realidad se cambió) para el archivo assume-unchanged .
  • Archivo con indicador de assume-unchanged : el contenido del archivo se revierte. La bandera se restablece en H (desde h ).
  • Archivo con indicador skip-worktree : el contenido del archivo está intacto. La bandera sigue siendo la misma.

Añade el siguiente análisis:

• Parece que skip-worktree está esforzando mucho para preservar sus datos locales . Pero no impide que se realicen cambios en sentido ascendente si es seguro. Además git no restablece la bandera al pull .
  Pero ignorar el comando '' reset --hard '' podría convertirse en una desagradable sorpresa para un desarrollador.

• Assume-unchanged podría perderse en la operación de pull y los cambios locales dentro de dichos archivos no parecen ser importantes para git.

Ver:

• El comentario de Junio ​​(actual mantenedor de git) con respecto a la intención de assume-unchanged ,

  En particular, Junio ​​señala que los cambios en assume-unchanged archivos de assume-unchanged podrían cometerse accidentalmente: "si Git puede determinar una ruta que está marcada como supuesta assume-unchanged ha cambiado sin incurrir en un costo adicional de lstat (2), se reserva el derecho de informar que la ruta se ha modificado (como resultado, git commit -a es libre de confirmar ese cambio) ".

• la diferencia entre assume-unchanged y skip-worktree como se discute en la lista de correo de git luego de skip-worktree parche de skip-worktree .

Concluye:

En realidad ninguna de las banderas es suficientemente intuitiva .

• assume-unchanged supone que un desarrollador no debe cambiar un archivo. Si un archivo fue cambiado, entonces ese cambio no es importante. Este indicador está destinado a mejorar el rendimiento de las carpetas que no cambian como los SDK.
  Pero si se rompe la promesa y se cambia un archivo, git invierte la bandera para reflejar la realidad. Probablemente está bien tener algunos indicadores inconsistentes en carpetas generalmente no destinadas a ser cambiadas.

• Por otro lado, skip-worktree es útil cuando le pides a git que no toque un archivo específico. Eso es útil para un archivo de configuración ya rastreado.
  El repositorio principal ascendente alberga algunas configuraciones listas para producción, pero le gustaría cambiar algunas configuraciones en la configuración para poder realizar algunas pruebas locales. Y no desea verificar accidentalmente los cambios en dicho archivo para afectar la configuración de producción. En ese caso, skip-worktree hace la escena perfecta.

Answer 2

Quieres skip-worktree .

assume-unchanged está diseñado para casos en los que es costoso verificar si se ha modificado un grupo de archivos; cuando establece el bit, git (por supuesto) asume que los archivos correspondientes a esa parte del índice no se han modificado en la copia de trabajo. Así que evita un lío de stat . Este bit se pierde cada vez que cambia la entrada del archivo en el índice (por lo tanto, cuando el archivo se cambia en sentido ascendente).

skip-worktree es más que eso: incluso cuando git sabe que el archivo ha sido modificado (o necesita ser modificado por un reset --hard o similar), fingirá que no lo ha sido, utilizando la versión del índice en su lugar . Esto persiste hasta que se descarta el índice.

Hay un buen resumen de las ramificaciones de esta diferencia y los casos de uso típicos aquí: http://fallengamer.livejournal.com/93321.html .

De ese artículo:

• --assume-unchanged supone que un desarrollador no debería cambiar un archivo. Este indicador está destinado a mejorar el rendimiento de las carpetas que no cambian, como los SDK.
• --skip-worktree es útil cuando le pides a git que no toque un archivo específico porque los desarrolladores deberían cambiarlo. Por ejemplo, si el repositorio principal principal contiene algunos archivos de configuración listos para producción y no quiere cometer cambios accidentalmente en esos archivos, --skip-worktree es exactamente lo que desea.