Estoy muy confundido acerca de cómo usarlo git archive.

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

Aprendí que podía usarlo git-archiveen una especie de exportación de SVN .

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, lo siguiente generará un error con fatal not a valid object name:

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

La documentación

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

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

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

La respuesta corta (TL; DR)

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

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

<rev>:<path>, Por ejemplo HEAD:README, :README,master:./README

Un sufijo :seguido de una ruta nombra el blob o el árbol en la ruta dada en el objeto en forma de árbol nombrado por la parte antes de los dos puntos.

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

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

Aquí hay una lista completa de identificadores de tipo 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", porque todos conducen a confirmaciones, pero debido a que las confirmaciones también apuntan a árboles de directorio, todos finalmente conducen a objetos de árbol de (sub) directorio y, por lo tanto, también se pueden usar como "árbol -ish ".

# 15 también se puede usar como árbol 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 si todavía se considera "tipo árbol", o si actúa más como "tipo blob" (Git se refiere a 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 confirmaciones.
2. Confirma, que apunta al árbol del 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 propio ID de hash sha1, 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 ID de sha1 se generan a partir del contenido del archivo). El libro Pro Git ofrece este diagrama de ejemplo :

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

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

  tag -> commit

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

  tag -> commit -> project-root-directory

Debido a que 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 lleve a un objeto de confirmación también se puede utilizar para llevar a un objeto de árbol de (sub) directorio .

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

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, un compromiso o un nombre de objeto de etiqueta. Un comando que toma un <tree-ish> argumento, en última instancia, quiere operar en un <tree>objeto, pero elimina automáticamente las referencias <commit>y los <tag>objetos que apuntan a un <tree>.

<commit-ish>

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

El conjunto de identificadores de tipo árbol que no se pueden utilizar como compromiso son

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

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

Un árbol 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 sucursales con controles remotos, como origin/somebranch
• Picadillo
• Hashes cortos

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

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

La mayoría de los anteriores se pueden combinar más, siempre y cuando 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, que es solo una forma de decir qué árbol (o revisión) es el que debe 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 .

Probablemente quieras

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

La expresión master/foono tiene sentido: masteres un nombre de rama y fooes un nombre de directorio, como supongo.

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

Para obtener definiciones de <tree-ish>y <commit-ish>consulte la página de manual de git (1) . Tendrá que buscar los términos. En general, <tree-ish>significa una referencia a un objeto de árbol de git, pero si pasa un tipo de objeto que hace referencia a un árbol (como una confirmación o una rama), git usará automáticamente el árbol de referencia.

Soy un novato en el control de fuentes y git. Eso es lo que sé. Un árbol es la estructura de archivos en un repositorio. Es similar a un directorio en un sistema de archivos. Consulte - ¿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 una confirmación utilizando cualquiera de estos: total o parte del hash SHA-1 de una confirmación, puntero HEAD, referencia de rama, referencia de etiqueta. Otro método usa cualquiera de los métodos mencionados junto con los antepasados ​​o padres de un compromiso. Ejemplo de antepasados:

De Git Glossary tree-ish es "Un objeto de árbol o un objeto que puede desreferenciarse recursivamente a un objeto de árbol". commit, HEAD y tag son ejemplos de objetos en forma de árbol.