git-read-tree: en línea en la nube

PROGRAMA:

NOMBRE

git-read-tree: lee la información del árbol en el índice

SINOPSIS

git árbol de lectura [[-m [--trivial] [--aggressive] | --reset | --prefix = ]
[-u [--excluir-por-directorio = ] | -I]]
[--index-output = ] [--no-pago-escaso]
(--vacío | [ [ ]])

DESCRIPCIÓN

Lee la información del árbol proporcionada por en el índice, pero en realidad no
actualización cualquiera de los archivos que "almacena en caché". (ver: índice-git-checkout(1))

Opcionalmente, puede fusionar un árbol en el índice, realizar una fusión de avance rápido (es decir, bidireccional),
o una combinación de 3 vías, con la bandera -m. Cuando se usa con -m, el indicador -u hace que también
actualice los archivos en el árbol de trabajo con el resultado de la fusión.

Las fusiones triviales se realizan mediante git árbol de lectura sí mismo. Solo los caminos conflictivos estarán en
estado no fusionado cuando git árbol de lectura devoluciones.

OPCIONES

-m
Realice una fusión, no solo una lectura. El comando se negará a ejecutarse si su archivo de índice
tiene entradas no fusionadas, lo que indica que no ha terminado la fusión anterior
comenzado.

--Reiniciar
Igual que -m, excepto que las entradas no fusionadas se descartan en lugar de fallar.

-u
Después de una combinación exitosa, actualice los archivos en el árbol de trabajo con el resultado de la
unir.

-i
Por lo general, una combinación requiere que el archivo de índice, así como los archivos en el árbol de trabajo
actualizado con el compromiso principal actual, para no perder los cambios locales. Esta bandera
deshabilita la verificación con el árbol de trabajo y está destinado a usarse al crear una combinación
de árboles que no están directamente relacionados con el estado actual del árbol de trabajo en un
archivo de índice temporal.

-n, --secar
Compruebe si el comando daría un error, sin actualizar el índice o los archivos en el
árbol de trabajo de verdad.

-v
Muestre el progreso de la extracción de archivos.

--trivial
Restringir la combinación de tres vías mediante git árbol de lectura que suceda solo si no hay un nivel de archivo
fusión requerida, en lugar de resolver la fusión para casos triviales y dejar conflictos
archivos sin resolver en el índice.

--agresivo
Por lo general, una combinación de tres vías por git árbol de lectura resuelve la fusión para casos realmente triviales
y deja otros casos sin resolver en el índice, para que las porcelanas puedan implementar
diferentes políticas de fusión. Esta bandera hace que el comando resuelva algunos casos más.
internamente:

· Cuando un lado elimina un camino y el otro lado deja el camino sin modificar. los
La resolución es eliminar ese camino.

· Cuando ambos lados eliminan un camino. La resolución es eliminar ese camino.

· Cuando ambos lados agregan un camino de manera idéntica. La resolución es agregar ese camino.

--prefijo = /
Mantenga el contenido del índice actual y lea el contenido del árbol nombrado debajo del
directorio en . El comando se negará a sobrescribir las entradas que ya
existía en el archivo de índice original. Tenga en cuenta que el / valor debe terminar con un
barra oblicua.

--excluir-por-directorio =
Al ejecutar el comando con las opciones -u y -m, es posible que el resultado de la combinación deba
sobrescribir las rutas que no se rastrean en la rama actual. El comando generalmente
se niega a continuar con la fusión para evitar perder ese camino. Sin embargo, esta seguridad
la válvula a veces se interpone en el camino. Por ejemplo, a menudo sucede que la otra rama
agregó un archivo que solía ser un archivo generado en su sucursal, y la válvula de seguridad
se activa cuando intenta cambiar a esa rama después de ejecutar make pero antes de ejecutar
hacer limpio para eliminar el archivo generado. Esta opción le dice al comando que lea
archivo de exclusión por directorio (generalmente .gitignore) y permite un seguimiento sin seguimiento pero
archivo explícitamente ignorado que se sobrescribirá.

--index-output =
En lugar de escribir los resultados en $ GIT_INDEX_FILE, escriba el índice resultante en
el archivo nombrado. Mientras el comando está en funcionamiento, el archivo de índice original se bloquea con
el mismo mecanismo de siempre. El archivo debe permitir ser rebautizar(2) ed en de un
archivo temporal que se crea junto al archivo de índice habitual; normalmente esto significa que
debe estar en el mismo sistema de archivos que el archivo de índice, y debe escribir
permiso para los directorios en los que se encuentran el archivo de índice y el archivo de salida del índice.

--no-pago-escaso
Deshabilite el soporte de pago disperso incluso si core.sparseCheckout es verdadero.

--vacío
En lugar de leer objetos de árbol en el índice, simplemente vacíelo.


El ID de los objetos de árbol que se leerán / fusionarán.

FUSIÓN

Si se especifica -m, git árbol de lectura puede realizar 3 tipos de fusión, una fusión de un solo árbol si
solo se da 1 árbol, una combinación de avance rápido con 2 árboles o una combinación de 3 vías si hay 3 árboles
previsto.

Individual Árbol ir
Si solo se especifica 1 árbol, git árbol de lectura funciona como si el usuario no especificara -m,
excepto que si el índice original tiene una entrada para un nombre de ruta dado, y el contenido de
la ruta coincide con el árbol que se está leyendo, se utiliza la información estadística del índice. (En otra
palabras, las estadísticas del índice tienen prioridad sobre las del árbol combinado).

Eso significa que si haces un git read-tree -m seguido de un git checkout-index -f
-u -a, el git índice de pago solo revisa las cosas que realmente cambiaron.

Esto se utiliza para evitar falsos aciertos innecesarios cuando git archivos diff se ejecuta tras git
árbol de lectura.

Two Árbol ir
Normalmente, esto se invoca como git read-tree -m $ H $ M, donde $ H es la confirmación principal del
repositorio actual, y $ M es la cabeza de un árbol externo, que está simplemente por delante de $ H
(es decir, estamos en una situación de avance rápido).

Cuando se especifican dos árboles, el usuario está diciendo git árbol de lectura el seguimiento:

1. El índice actual y el árbol de trabajo se derivan de $ H, pero el usuario puede tener
cambios en ellos desde $ H.

2. El usuario desea avanzar rápidamente a $ M.

En este caso, el comando git read-tree -m $ H $ M se asegura de que no se pierda ningún cambio local
como resultado de esta "fusión". Aquí están las reglas de "arrastre", donde "I" denota el
índice, "limpio" significa que el índice y el árbol de trabajo coinciden, y "existe" / "nada" se refieren a
la presencia de una ruta en la confirmación especificada:

Resultado IHM
-------------------------------------------------- -----
0 nada nada nada (no pasa)
1 nada, nada existe use M
2 no existe nada elimina la ruta del índice
3 no existe nada, use M si "pago inicial",
H == M mantener el índice de lo contrario
existe, falla
H! = M

limpio I == HI == M
------------------
4 sí N / AN / A nada nada mantener índice
5 no N / AN / A nada nada mantener índice

6 sí N / A sí no existe nada mantener índice
7 no N / A si no existe nada mantener índice
8 sí N / A no no existe nada falla
9 no N / A no existe nada falla

10 sí sí N / A existe nada eliminar ruta del índice
11 no si N / A existe nada falla
12 si no N / A existe nada falla
13 no no N / A existe nada falla

limpio (H == M)
------
14 sí existe existe mantener índice
15 no existe existe mantener índice

limpio I == HI == M (H! = M)
------------------
16 si no no existe existe falla
17 no no no existe existe falla
18 si no si existe existe mantener índice
19 no no si existe existe mantener índice
20 si si no existe existe use M
21 no si no existe existe falla

En todos los casos de "mantener índice", la entrada de índice permanece como en el archivo de índice original. Si el
la entrada no está actualizada, git árbol de lectura mantiene la copia en el árbol de trabajo intacta cuando
operando bajo la bandera -u.

Cuando esta forma de git árbol de lectura devuelve correctamente, puede ver cuál de los "locales
los cambios "que hiciste se trasladaron al ejecutar git diff-index --cached $ M. Nota
que esto no necesariamente coincide con lo que git diff-index --cached $ H habría producido
antes de que esos dos árboles se fusionen. Esto se debe a los casos 18 y 19 --- si ya tuvo
los cambios en $ M (por ejemplo, tal vez lo recogió por correo electrónico en un formulario de parche), git diff-index
--cached $ H le habría informado sobre el cambio antes de esta fusión, pero no se mostraría
en git diff-index: salida en caché de $ M después de la fusión de dos árboles.

El caso 3 es un poco complicado y necesita explicación. El resultado de esta regla lógicamente
debería ser eliminar la ruta si el usuario organizó la eliminación de la ruta y luego cambió
a una nueva sucursal. Sin embargo, eso evitará que se realice el pago inicial, por lo que el
La regla se modifica para usar M (árbol nuevo) solo cuando el contenido del índice está vacío.
De lo contrario, la eliminación de la ruta se mantiene siempre que $ H y $ M sean iguales.

3-Way ir
Cada entrada de "índice" tiene dos bits de estado de "etapa". la etapa 0 es la normal y es
el único que verías en cualquier tipo de uso normal.

Sin embargo, cuando lo haces git árbol de lectura con tres árboles, la "etapa" comienza en 1.

Esto significa que puedes hacer

$ git árbol de lectura -m

y terminará con un índice con todos los entradas en "etapa1", todas las
entradas en "stage2" y todas las entradas en "stage2". Al realizar una
fusión de otra rama en la rama actual, usamos el árbol ancestro común como
, el jefe de rama actual como , y la otra rama como .

Además, git árbol de lectura tiene una lógica de caso especial que dice: si ve un archivo que
coincide en todos los aspectos en los siguientes estados, "colapsa" de nuevo a "stage0":

· Las etapas 2 y 3 son iguales; tomar uno o el otro (no hay diferencia - lo mismo
se ha trabajado en nuestra sucursal en la etapa 2 y su sucursal en la etapa 3)

· La etapa 1 y la etapa 2 son iguales y la etapa 3 es diferente; tomar la etapa 3 (nuestra sucursal en
la etapa 2 no hizo nada desde el antepasado en la etapa 1 mientras que su rama en la etapa
3 trabajaron en eso)

· La etapa 1 y la etapa 3 son iguales y la etapa 2 es diferente, tome la etapa 2 (hicimos
algo mientras no hacían nada)

El elemento git árbol de escritura comando se niega a escribir un árbol sin sentido, y se quejará de
entradas no fusionadas si ve una sola entrada que no es la etapa 0.

De acuerdo, todo esto suena como una colección de reglas totalmente absurdas, pero en realidad es
exactamente lo que desea para realizar una fusión rápida. Las diferentes etapas representan el
"árbol de resultados" (etapa 0, también conocido como "fusionado"), el árbol original (etapa 1, también conocido como "orig") y el
dos árboles que está intentando fusionar (etapa 2 y 3 respectivamente).

El orden de las etapas 1, 2 y 3 (de ahí el orden de tres línea de comando
argumentos) son importantes cuando inicia una combinación de 3 vías con un archivo de índice que ya está
poblado. A continuación, se muestra un resumen de cómo funciona el algoritmo:

· Si existe un archivo en formato idéntico en los tres árboles, automáticamente
colapsar al estado "fusionado" por git árbol de lectura.

· Un archivo que tiene cualquier diferencia lo que sea en los tres árboles se mantendrá como separado
entradas en el índice. Depende de la "política de porcelana" determinar cómo quitar el
etapas distintas de 0 e inserte una versión combinada.

· El archivo de índice se guarda y restaura con toda esta información, para que pueda combinar cosas
incrementalmente, pero siempre y cuando tenga entradas en las etapas 1/2/3 (es decir, "sin fusionar
entradas ") no puede escribir el resultado. Así que ahora el algoritmo de combinación termina siendo realmente
sencillo:

· Recorre el índice en orden e ignora todas las entradas de la etapa 0, ya que han
ya se ha hecho.

· Si encuentra un "stage1", pero no coincide con "stage2" o "stage3", sabrá que ha sido
eliminado de ambos árboles (solo existía en el árbol original), y elimina
esa entrada.

· Si encuentra un árbol "stage2" y "stage3" que coincida, elimine uno de ellos y
convierte el otro en una entrada "stage0". Elimina cualquier entrada "stage1" que coincida si
existe también. .. todas las reglas triviales normales ..

Normalmente usarías git índice de fusión con suministrado git fusionar un archivo para hacer esto último
paso. El script actualiza los archivos en el árbol de trabajo a medida que fusiona cada ruta y en el
final de una fusión exitosa.

Cuando inicia una combinación de 3 vías con un archivo de índice que ya está poblado, se asume
que representa el estado de los archivos en su árbol de trabajo, e incluso puede tener archivos
con cambios no registrados en el archivo de índice. Se asume además que este estado es
"derivado" del árbol de la etapa 2. La combinación de 3 vías se niega a ejecutarse si encuentra una entrada en
el archivo de índice original que no coincide con la etapa 2.

Esto se hace para evitar que pierda los cambios del trabajo en curso y mezcle sus
cambios aleatorios en una confirmación de fusión no relacionada. Para ilustrar, suponga que parte de lo que
se ha enviado por última vez a su repositorio:

$ JC = `git rev-parse --verify" HEAD ^ 0 "`
$ git checkout-index -f -u -a $ JC

Haces ediciones aleatorias, sin ejecutar git índice de actualización. Y luego notas que la punta de
su árbol "corriente arriba" ha avanzado desde que lo sacó:

$ git fetch git: // .... linus
$ LT = `git rev-parse FETCH_HEAD`

Su árbol de trabajo todavía se basa en su HEAD ($ JC), pero tiene algunas ediciones desde entonces. De tres vías
fusionar se asegura de que no haya agregado o modificado entradas de índice desde $ JC, y si
no lo ha hecho, entonces hace lo correcto. Entonces con la siguiente secuencia:

$ git árbol de lectura -m -u `git merge-base $ JC $ LT` $ JC $ LT
$ git merge-index git-merge-one-file -a
$ echo "Fusionar con Linus" | \
git árbol de confirmación `git árbol de escritura` -p $ JC -p $ LT

lo que comprometería es una fusión pura entre $ JC y $ LT sin su trabajo en progreso
cambios, y su árbol de trabajo se actualizará al resultado de la fusión.

Sin embargo, si tiene cambios locales en el árbol de trabajo que serían sobrescritos por este
unir, git árbol de lectura se negará a ejecutarse para evitar que se pierdan los cambios.

En otras palabras, no hay necesidad de preocuparse por lo que existe solo en el árbol de trabajo. Cuando
tiene cambios locales en una parte del proyecto que no está involucrada en la fusión, su
los cambios no interfieren con la fusión y se mantienen intactos. Cuando ellos do interferir, el
la fusión ni siquiera comienzagit árbol de lectura se queja fuerte y falla sin modificar
cualquier cosa). En tal caso, simplemente puede continuar haciendo lo que estaba en medio de
haciendo, y cuando su árbol de trabajo esté listo (es decir, haya terminado su trabajo en progreso),
intente la fusión de nuevo.

ESCASO FINALIZAR COMPRA

"Pago disperso" permite poblar el directorio de trabajo escasamente. Utiliza el
bit de skip-worktree (ver índice de actualización de git(1)) para decirle a Git si un archivo en el trabajo
vale la pena mirar el directorio.

git árbol de lectura y otros comandos basados ​​en fusiones (git unir, git caja...) poder ayudar
manteniendo el mapa de bits skip-worktree y la actualización del directorio de trabajo.
$ GIT_DIR / info / sparse-checkout se usa para definir el mapa de bits de referencia de skip-worktree. Cuando
git árbol de lectura necesita actualizar el directorio de trabajo, restablece el bit skip-worktree en
el índice basado en este archivo, que utiliza la misma sintaxis que los archivos .gitignore. Si una entrada
coincide con un patrón en este archivo, skip-worktree no se establecerá en esa entrada. De lo contrario,
Se establecerá skip-worktree.

Luego compara el nuevo valor skip-worktree con el anterior. Si skip-worktree gira
de armado a desarmado, volverá a agregar el archivo correspondiente. Si pasa de desarmado a armado,
ese archivo será eliminado.

Si bien $ GIT_DIR / info / sparse-checkout se usa generalmente para especificar en qué archivos están, puede
también especifique qué archivos son No adentro, usando patrones de negación. Por ejemplo, para eliminar el archivo
no deseado:

/*
!no deseado

Otra cosa complicada es repoblar completamente el directorio de trabajo cuando ya no quieras
pago escaso. No puede simplemente deshabilitar "pago disperso" porque los bits de salto de árbol de trabajo son
todavía en el índice y su directorio de trabajo todavía está escasamente poblado. Debería
vuelva a llenar el directorio de trabajo con el contenido del archivo $ GIT_DIR / info / sparse-checkout como
manera:

/*

Entonces puede deshabilitar el pago disperso. Soporte de pago escaso en git árbol de lectura y similar
Los comandos están deshabilitados de forma predeterminada. Debe activar core.sparseCheckout para tener
soporte de pago escaso.

Use git-read-tree en línea usando los servicios de onworks.net