trucos tag qué que name hace conectar con commits commands comentarios git git-archive

tag - qué es un branch en git



¿Qué significa tree-ish en Git? (5)

Estoy muy confundido sobre cómo usar git archive .

Tengo un repositorio git con la carpeta Foo , Bar y Baz en el nivel superior. Necesito exportar la carpeta Foo en una especie de SVN-ish para una implementación de prueba rápida.

Aprendí que podía usar git-archive en una especie de exportación SVN-ish .

Pero aquí está la cosa, lo siguiente funciona bien:

git archive master | tar -x -C ~/destination

da como resultado las carpetas Foo , Bar , Baz en la carpeta de destino .

Sin embargo, el siguiente mensaje error con fatal not a valid object name :

git archive master/foo | tar -x -C ~/destination

La documentación

Mirando la sinopsis del programa de git archive , veo que puede tomar un <tree-ish> [path] como parámetro (sinopsis resumida en partes relevantes):

git archive <tree-ish> [path...]

Si master/foo no es tree-ish , entonces ¿qué es?

La respuesta corta (TL; DR)

"Tree-ish" es un término que hace referencia a cualquier identificador (como se especifica en la documentación de revisiones de Git ) que finalmente conduce a un árbol de (sub) directorios (Git se refiere a directorios como "árboles" y "objetos de árbol").

En el caso del afiche original, foo es un directorio que quiere especificar. La forma correcta de especificar un (sub) directorio en Git es usar esta sintaxis "tree-ish" (elemento # 15 de la documentación de revisiones de Git ):

<rev>:<path> , p. ej. HEAD:README :README , master:./README

Un sufijo : seguido de una ruta de nombres del blob o árbol en la ruta dada en el objeto tree-ish nombrado por la parte antes de los dos puntos.

Entonces, en otras palabras, master:foo es la sintaxis correcta, no master/foo .

Otro "Tree-ish" (Plus Commit-ish)

Aquí hay una lista completa de identificadores commit-ish y tree-ish (de la documentación de revisiones de Git , gracias a LopSae por señalarlo ):

---------------------------------------------------------------------- | Commit-ish/Tree-ish | Examples ---------------------------------------------------------------------- | 1. <sha1> | dae86e1950b1277e545cee180551750029cfe735 | 2. <describeOutput> | v1.7.4.2-679-g3bee7fb | 3. <refname> | master, heads/master, refs/heads/master | 4. <refname>@{<date>} | master@{yesterday}, HEAD@{5 minutes ago} | 5. <refname>@{<n>} | master@{1} | 6. @{<n>} | @{1} | 7. @{-<n>} | @{-1} | 8. <refname>@{upstream} | master@{upstream}, @{u} | 9. <rev>^ | HEAD^, v1.5.1^0 | 10. <rev>~<n> | master~3 | 11. <rev>^{<type>} | v0.99.8^{commit} | 12. <rev>^{} | v0.99.8^{} | 13. <rev>^{/<text>} | HEAD^{/fix nasty bug} | 14. :/<text> | :/fix nasty bug ---------------------------------------------------------------------- | Tree-ish only | Examples ---------------------------------------------------------------------- | 15. <rev>:<path> | HEAD:README, :README, master:./README ---------------------------------------------------------------------- | Tree-ish? | Examples ---------------------------------------------------------------------- | 16. :<n>:<path> | :0:README, :README ----------------------------------------------------------------------

Los identificadores # 1-14 son todos "commit-ish", ya que todos conducen a confirmaciones, pero debido a que los commits también apuntan a árboles de directorio, todos conducen finalmente a objetos de árbol (sub) de directorio y, por lo tanto, también pueden usarse como "árbol -ish ".

# 15 también se puede utilizar como árbol-ish cuando se refiere a un (sub) directorio, pero también se puede usar para identificar archivos específicos. Cuando se refiere a archivos, no estoy seguro de si todavía se considera "tree-ish", o si actúa más como "blob-ish" (Git se refiere a los archivos como "blobs").

La respuesta larga

En sus niveles más bajos, Git realiza un seguimiento del código fuente utilizando cuatro objetos fundamentales:

  1. Etiquetas anotadas, que apuntan a commits.
  2. Commite, que apunta al árbol de directorio raíz de su proyecto.
  3. Árboles, que son directorios y subdirectorios.
  4. Blobs, que son archivos.

Cada uno de estos objetos tiene su propia identificación shal hash, ya que Linus Torvalds diseñó Git como un sistema de archivos direccionable por contenido , es decir, los archivos se pueden recuperar en función de su contenido (los identificadores sha1 se generan a partir del contenido del archivo). El libro de Pro Git da este diagrama de ejemplo :

Muchos comandos de Git pueden aceptar identificadores especiales para commits y árboles (sub) de directorios:

  • "Commit-ish" son identificadores que finalmente conducen a un objeto de commit. Por ejemplo,

    tag -> commit

  • "Tree-ish" son identificadores que finalmente conducen a objetos de árbol (es decir, directorio).

    tag -> commit -> project-root-directory

Como los objetos de confirmación siempre apuntan a un objeto de árbol de directorio (el directorio raíz de su proyecto), cualquier identificador que sea "commit-ish" es, por definición, también "tree-ish". En otras palabras, cualquier identificador que conduzca a un objeto de confirmación también puede usarse para conducir a un objeto de árbol (sub) de directorio .

Pero dado que los objetos de árbol de directorios nunca apuntan a confirmaciones en el sistema de control de versiones de Git, no todos los identificadores que apuntan a un árbol de (sub) directorios también pueden usarse para apuntar a un compromiso. En otras palabras, el conjunto de identificadores "commit-ish" es un subconjunto estricto del conjunto de identificadores "tree-ish".

Como se explica en la documentación ( gracias a Trebor por ayudarme a encontrarlo ):

<tree>

Indica un nombre de objeto de árbol.

<commit>

Indica un nombre de objeto de confirmación.

<tree-ish>

Indica un árbol, confirmar o etiquetar el nombre del objeto. Un comando que toma un argumento <tree-ish> en última instancia quiere operar en un objeto <tree> pero elimina automáticamente los objetos <commit> y <tag> que apuntan a un <tree> .

<commit-ish>

Indica un nombre de objeto de compromiso o etiqueta. Un comando que toma un argumento <commit-ish> en última instancia quiere operar en un objeto <commit> pero elimina automáticamente los objetos <tag> que apuntan a un <commit> .

El conjunto de identificadores tree-ish que no se pueden usar como commit-ish son

  1. <rev>:<path> , que conduce directamente a árboles de directorios, no a objetos. Por ejemplo, HEAD:subdirectory .

  2. Identificadores Sha1 de objetos de árbol de directorio .

Para las definiciones de <tree-ish> y <commit-ish> vea la página man de git(1) . Tendrás que buscar los términos. En general, <tree-ish> significa una referencia a un objeto de árbol git, pero si pasa un tipo de objeto que hace referencia a un árbol (como una confirmación o una bifurcación), git utilizará automáticamente el árbol al que se hace referencia.

Probablemente quieras

git archive master foo | tar -x -C ~/destination

La expresión master/foo no tiene sentido: master es un nombre de rama y foo es un nombre de directorio, como supongo.

Editar : (Se eliminó el enlace roto. Ver comentarios).

Soy un novato en control de fuente y git. Esto es lo que sé. Un árbol es la estructura de los archivos en un repositorio. Es similar a un directorio en un sistema de archivos. Ver - ¿Qué herramienta git generó esta vista de árbol?

Tree-ish significa como un árbol. Hace referencia a una parte o compromiso de un árbol. Puede hacer referencia a un compromiso utilizando cualquiera de estos: completo o parte del hash SHA-1 de un commit, puntero HEAD, referencia de bifurcación, referencia de etiqueta. Otro método utiliza cualquiera de los métodos mencionados junto con ancestros o padres de una confirmación. Ejemplo de antepasados:

Un árbol-ish es una forma de nombrar un árbol específico que puede ser uno de los siguientes:

  • Referencias como:
    • CABEZA
    • Etiquetas
    • Nombres de sucursales
    • Nombres de origin/somebranch con controles remotos, como origin/somebranch
  • Picadillo
  • Hashes cortos

Además de eso, cualquiera de los anteriores se puede agregar con ^ , ~ . Las referencias también pueden usar la notación @{} para algunas características adicionales:

  • HEAD^ o HEAD^1 se resolverá con el primer padre de HEAD.
  • HEAD^2 se resolverá con el segundo padre
  • HEAD^3 se resolverá con el tercer padre y así sucesivamente, lo cual es más raro y producto de las fusiones con la estrategia del pulpo .
  • HEAD~ o HEAD~1 se resolverá con el primer padre de la cabeza
  • HEAD~2 se resolverá con el primer padre del primer padre de HEAD. Esto sería lo mismo que HEAD^^
  • HEAD@{0} se resolverá con el HEAD actual
  • HEAD@{1} se resolverá a la cabeza anterior. Esto solo puede ser usado por referencias ya que hace uso del registro de referencia. En el caso de HEAD cada commit, merge, checkout cambiará el valor de HEAD y así lo agregará al log. git reflog HEAD mostrará el registro de referencia en el que se pueden ver todos los movimientos de HEAD y en qué se resolverá @{1} y así sucesivamente.

La mayoría de los anteriores se pueden combinar más, siempre que tenga sentido en su repositorio, por ejemplo: HEAD@{2}~3 , somebranch^2~4 , c00e66e~4^2 , anotherbranch~^~^~^ .

Entonces, cualquiera de los descritos anteriormente, y sus combinaciones, es lo que se entiende en la documentación como un árbol-ish, que es solo una forma de decir qué árbol (o revisión) es el que debería usarse para la mayoría de los comandos de git.

Más información en Selección de revisión en el libro de Git .