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:
- Etiquetas anotadas, que apuntan a confirmaciones.
- Confirma, que apunta al árbol del directorio raíz de su proyecto.
- Árboles, que son directorios y subdirectorios.
- 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
<rev>:<path>, que conduce directamente a árboles de directorios, no a enviar objetos. Por ejemplo HEAD:subdirectory,.
Identificadores Sha1 de objetos de árbol de directorio .
master:fooes un árbol, pero es mejor usarlomaster foocomo i<tree-ish> <path>.