¿qué significa alcanzable/inalcanzable en git?

poco confundido ..¿qué significa alcanzable/inalcanzable en git?

En el git community manual, que dice comando de registro

El GIT puede mostrar listas de confirmaciones. Por sí solo, muestra todos los commit accesibles desde el padre commit; pero también se puede hacer más peticiones específicas

$ git log v2.5.. # commits since (not reachable from) v2.5

pensé git log por sí mismo sólo le las confirmaciones hechas a la rama actual muestra, y las confirmaciones son secuenciales - así que ¿cómo se puede tener uno commit hecho ya otro, pero inalcanzable de eso?

Creo que estoy entendiendo lo que hace el log git o lo que significa inalcanzable o ambos ... ¡muy agradecido por cualquier ayuda!

Fuente

2010-11-06 bruce

Oh, creo que lo estoy obteniendo. Como cada confirmación solo almacena sus elementos principales, puede crear una lista de confirmaciones desde cualquier confirmación, pero no reenviar. Por lo tanto, cualquier compromiso desde entonces tampoco es alcanzable. – bruce

Correcto. Así es como git encuentra toda la información. Comienza desde un punto conocido determinado (por ejemplo, una bifurcación, que apunta a un objeto de confirmación dado), y sigue su camino desde allí a través de las referencias a otros objetos (por ejemplo, los padres de la confirmación).Esto es lo mismo que la forma en que encuentra el contenido asociado con la confirmación: recorre eficazmente la estructura de directorios (representada internamente como árboles) para cada archivo (cuyos contenidos se almacenan como blobs). – Cascabel

en Git, cada confirmación que realice (excepto la primera) tendrá una confirmación principal. Se sigue que cualquier compromiso dado (excepto el primero) es un hijo de uno (o posiblemente más de un) otro compromiso. También puede tener varias ramas de desarrollo en Git, que comienzan o se desvían en un compromiso ancestral particular. Nada en Git dicta que las confirmaciones deben ocurrir en un orden cronológico o lineal, y por lo tanto, la herramienta git log debe ser capaz de manejar varias formas de consultar el historial.

Por ejemplo, supongamos que desarrollo mi solicitud y hacer commit en orden alfabético:

---A---B---E---G 
    \  \ 
    C---D F

En este ejemplo, debo haber hecho una nueva rama de cometer A y E.

Si fuera para funcionar git log <D> (donde <D> es el de comprometerse SHA), entonces el historial de registro se vería así:

D---C---A---

de esa confirmación, sólo el los padres y sus ancestros se comprometen pueden ser 'vistos'. Los compromisos B, E, F y G son técnicamente 'inalcanzables' del compromiso D, ya que no comparten ningún compromiso principal conectado común.

Fuente

2010-11-06 04:21:00 Chris

Gracias. Eso tiene perfecto sentido. – bruce

Esto es un poco confusamente escrito: las marcas de tiempo no tienen nada que ver con eso. Y 'git log' no realmente" consulta el historial "de ninguna manera, sino de" ancestral ". Si le pide algo cronológico, todavía camina por la cadena de ancestros de compromiso; simplemente también examina los metadatos y aplica su restricción de tiempo. – Cascabel

sí, tiene toda la razón: las marcas de tiempo tienen poco que ver con la forma en que funciona el registro de git. Estaba intentando ilustrar eso, aunque puedo ilustrar mejor el punto. – Chris

"Y es alcanzable desde X" significa que se puede acceder al objeto Y desde DAG. Depende de lo que Y es, esto puede significa:

Y es una confirmación: Y es un padre/ancestro de X.
Y es un directorio/carpeta/blob: Y es una parte de (para decir) una confirmación en el árbol padre/ancestro de X.

Para algunos documentos (por ejemplo, git-fsck), solo dice "Y es alcanzable". Esto significa que se puede alcanzar Y desde alguna etiqueta/bifurcación (es decir, Y no se puede recolectar basura)

Fuente

2010-11-06 04:18:00

Consejo: como novato git, es poco probable que sepa lo que DAG significa. Toda tu respuesta pasó por mi cabeza. – bruce

@bruce: gráfico acíclico dirigido. Todo en git se basa en esto. Un objeto commit contiene una referencia a sus padres, pero no su hijo (s). Del mismo modo, un commit conoce su árbol (esencialmente listado de directorio), que sabe qué blobs (esencialmente contenido de archivo) y otros árboles que contiene, y así sucesivamente, pero ninguno de ellos conoce a sus padres. Ver por ejemplo el [modelo de objetos git] (http://book.git-scm.com/1_the_git_object_model.html) en el libro de la comunidad git. – Cascabel

He agregado un enlace a http://eagain.net/articles/git-for-computer-scientists/ (git para informáticos) –

¿qué significa alcanzable/inalcanzable en git?

Respuesta

Cuestiones relacionadas