- opción de ejecución antigua en git checkout

Question

Uso git checkout --<dir_name(or)file_name> para descartar todos mis cambios en el directorio específico o en el archivo. Cada vez que hago eso, GIT marca el directorio (o) del repositorio.

¿Hay una manera que puedo decir ?, GIT "no anulan los cambios, sólo dime lo que sucedería."

similares a git clean -n (o) git clean --dry-run.

ACTUALIZACIÓN: Antes ejecuto, git checkout --src/, me gustaría ver lo que son los archivos de ellos será ignorado. Sé que podemos usar git status src/. Pero, ¿no sería genial tener git checkout -n --src/? No hay muchos cambios de comando para el usuario.

Answer 1

Puede ejecutar

$ git checkout --patch -- <files> 

y va a pedir cada diferencia si quiere "check out" esa diferencia. Si dices que no para cada aviso, entonces lo deja intacto.

Answer 2

No estoy seguro, pero como un trabajo en torno no podría git stash -u luego git apply luego git checkout?

Siempre puede volver al alijo si no está satisfecho.

Answer 3

El comando Git checkout no tiene una opción dry-run (o similar). Sin embargo, puede utilizar el comando Git ls-files para ver qué archivos de directorio de trabajo difieren de HEAD:

git ls-files -dm -- src/ 

Esto mostrará una lista de todos los archivos que han sido borrados o modificados, los archivos que normalmente se sobrescriben en un checkout.

Otra opción es utilizar el comando Git diff:

git diff --name-only HEAD -- src/ 

Esta lista de todos los archivos que se diferencian de HEAD y serían reemplazados en un checkout.

Si esto es algo que se hace a menudo, es posible que desee crear un alias:

git config --global alias.lco "diff --name-only HEAD" 

continuación, puede utilizar:

git lco -- src/ 

Answer 4

Si se quiere evitar la interactividad (al estilo de "diga no a cada aviso"), use git diff. Si quiere una respuesta exacta a su pregunta, use git diff -R. Si solo desea nombres de archivos, use git diff --name-only.

Sin la bandera -R, git diff informará todas las diferencias entre su árbol de trabajo y su índice en un formato de parche, es decir, el formato que se ve cuando se emite git show <commit>. El -R invierte la salida, mostrándole qué pasaría si se eliminaran los cambios, como si la eliminación fuera en sí un parche.Considere un ejemplo:

git init /tmp/test && cd /tmp/test 
echo "old line">file 
git add . 
git commit -m "Initial commit" 
echo "new line">file 

ahora publique git diff sin ninguna marca. Usted debe obtener:

$ git diff 
diff --git a/file b/file 
index 0906fba..86ba82a 100644 
--- a/file 
+++ b/file 
@@ -1 +1 @@ 
-old line 
+new line 

Francamente, me parece que la producción lo suficientemente fácil de analizar que nunca uso la bandera -R. Si emite rutinariamente comandos git diff (y considero que es uno de los comandos más comunes que uso), la salida invertida probablemente no sea necesaria. De todos modos, a los efectos de esta respuesta, intente:

$ git diff -R 
git diff -R 
diff --git b/file a/file 
index 86ba82a..0906fba 100644 
--- b/file 
+++ a/file 
@@ -1 +1 @@ 
-new line 
+old line 

que la producción describe exactamente lo que buscan: "no anular los cambios, sólo dime lo que sucedería".

De forma predeterminada, ese comando diferirá todo su directorio de trabajo con el índice. Te mostrará los diffs en cada archivo modificado. Supongamos que solo quiere ver el efecto en un archivo. Eso es fácil. Sólo tiene que utilizar la misma nomenclatura de doble tablero ya está usando:

git diff -- <file> 

Encontrará git diff a ser uno de los comandos más útiles, extensibles en Git, y se puede utilizar para hacer todo tipo de útiles cosas. Puede usarlo para comparar dos confirmaciones, dos ramas o dos archivos. Mi "operación crazy git loca" más reciente es la tubería git diff a git apply. El primero produce parches inteligibles. Este último los aplica. Su capacidad para reescribir el historial cuando se combinan es casi ilimitada; localmente, por supuesto, , nunca vuelva a escribir el historial compartido. Considere otro ejemplo, en este momento fuera del tema pero seriamente entretenido (si usted está en este tipo de cosas). De nuestro repositorio de pruebas, arriba:

git add . 
git commit -m "Second commit" 
echo "even newer line">file 
git add . 
git commit -m "Third commit" 

¿Sabes qué? No me gustó ese segundo comprometerse mucho. Su implementación fue con errores. Está rompiendo pruebas. No quiero compartirlo Sin embargo, sí quiero mantener el mensaje de confirmación "Segundo compromiso" porque era muy difícil de escribir. Podría volver a establecer una base de datos con git rebase -i HEAD~2, pero eso implica abrir el editor, eliminar una confirmación, editar otra y (ugh) copiar/pegar. ¿Qué debe hacer un desarrollador? ¿Qué tal esto:

git checkout ":/Initial" ;# get back to the first commit 
git diff HEAD ":/Third" | git apply ;# apply the diff between the first and third commit 
git add . ;# add the result 
git commit -C ":/Second" ;# with second commit's message 
git checkout -B master HEAD ;# and replace old 'master' 

El resultado es el mismo que el que sería con git rebase. Solo pude evitar las sesiones interactivas y no tuve que usar el editor. ¿Es excesivo? Probablemente, pero seguro que es divertido. Además, es fácil construir casos de uso mucho más complicados, especialmente cuando combina git diff, git apply y git add -p.

Answer 5

Desea una opción de ejecución en seco para cualquier comando, independientemente de la supuesta idea de que "no necesita una ejecución en seco para el pago porque puede obtener una lista de diferencias de otras maneras".

No desea tener una opción de ejecución en seco para obtener una lista de diferencias, quiere que la ejecución en seco verifique "¿Qué sucederá cuando presione enter?" antes de hacerlo de verdad Hay una diferencia. Está probando el comportamiento real/exacto de un programa cuando puede haber alguna ambigüedad si todo lo que hizo fue leer el manual.

Tengo un proyecto extraño donde el repositorio se basa en '/'. Entonces, hay un directorio '/ git' y archivos '/.gitignore' y '/.gitmodules'. El /.gitignore y /.Los archivos de gitmodules se rastrean en el repositorio, y eso es un problema porque incluso si el usuario desarrollador tiene permiso para editar el archivo, aún no tiene permiso para eliminar y volver a crear el archivo, ya que el no puede y puede 't, tiene permiso de escritura en'/'. Si git edita archivos en el lugar no habría ningún problema, pero git lo elimina y lo reemplaza, porque un usuario obtiene un error que git no puede desvincular el archivo. En el transcurso del desarrollo de un cambio en nuestra configuración de recompra, y algunas instrucciones para los desarrolladores seguir para eliminar este problema en el futuro, a lo largo de la manera que quiero saber qué va a hacer este comando:

git checkout master -- /.git*

y otra posibles variaciones como

git checkout master -- '/.git*'

y otros, el cambio de la cáscara de englobamiento y/o ver cómo git en sí podría interpretar el valor especificaciónDeArchivo final. Si escapo un '*' del shell, ¿se expandirá un '*', o lo tratará como un literal? Si lo expande, ¿incluiría el directorio '/.git/'? Si lo expande, ¿hay alguna sintaxis de expresiones regulares que podría usar que signifique 'cualquier-único-carácter no vacío' como un '.' en expresiones regulares o un '?' ¿en globbing de concha? etc etc

No quiero saber qué archivos son diferentes, quiero probar el comportamiento exacto de git para encontrar la mejor/más simple versión de un comando inusual o un conjunto de comandos.

Para eso, realmente quieres una opción de funcionamiento en seco. Ya sé qué archivos son diferentes. En este caso, MUCHOS archivos serían diferentes, y no quiero ninguno. Solo quiero /.gitignore y /.gitmodules y nada más.

En este caso, sé que puedo hacer eso simplemente especificándolos explícitamente en la línea de comandos.

git checkout master -- /.gitignore /.gitmodules

Pero quiero ver si hay una sintaxis globbing más corto que hará que los dos de forma automática, sin embargo, lo ideal, para no incluir el directorio /.git. E idealmente, me gustaría averiguar cuál es la forma más simple en la que puedo salirse con la suya. Sé que podría usar el intérprete de comandos para hacer una expansión elegante y muy específica, pero si algo como '/ git *' funciona, prefiero usar eso que '/ git {i, m} *'

Este particular la tarea es pequeña y tiene varias respuestas simples. Por favor, no me diga formas de resolver ESTE PROBLEMA EXACTO sin "git checkout --dry-run", o dígame qué tan estúpido fue hacer un repositorio en /, lo sé también. Ya sé varias maneras de hacer mi trabajo inmediato. Ese no es el punto. Podría haber involucrado fácilmente más archivos o un patrón globbing más complicado de modo que no habría sido tan conveniente simplemente listar los archivos explícitamente, o podría haber sido un tipo de problema completamente diferente.

El punto es, en general, se aplica a cualquier comando en cualquier lugar, incluido el pago de git, siempre hay una opción de ejecución en seco para probar el comportamiento de un programa. Leer el manual o --ayuda no responde la pregunta respondida por ejecución en seco.