Parar subdirectorios en Git?

Question

¿Es posible consultar los subdirectorios de un repositorio en Git?

Imagine que estoy configurando una nueva instalación de WordPress. Voy a crear dos nuevos directorios para mi plugin y tema de la personalización:

• wordpress/wp-content/plugins/myplugins/
• wordpress/wp-content/themes/mytheme/

quiero mantener estos directorios a través de Git. En Subversion, lograría esto teniendo los directorios trunk/myplugins/ y trunk/mytheme/ y revisando los subdirectorios. ¿Tiene Git una manera de lograr la misma tarea usando un único repositorio?

Podría estar perdiendo el barco en algún paradigma de Git, como un usuario de SVN desde hace mucho tiempo con poca exposición a Git.

Editar:Multiple branches almacenar diferentes contenidos es una forma interesante de manejar esto.

Answer 1

Sparse checkouts son now in Git 1.7.

Consulte también la pregunta "Is it possible to do a sparse checkout without checking out the whole repository first?".

Tenga en cuenta que obtenciones parciales todavía requieren que descarga del repositorio completo, a pesar de que algunos de los archivos de Git descargas no va a terminar en su árbol de trabajo.

Answer 2

No hay forma de hacerlo en git. Y si no hará cambios que afecten a ambos árboles a la vez como una única unidad de trabajo, no hay una buena razón para usar un único repositorio para ambos. Pensé que echaría de menos esta característica de Subversion, pero descubrí que la creación de repositorios tiene muy poca carga administrativa administrativa (simplemente porque los repositorios se almacenan junto a su copia de trabajo, en lugar de requerir que busque explícitamente un lugar fuera del copia de trabajo) que me acostumbré a hacer muchos repositorios pequeños de un solo propósito.

Si insistes (o realmente lo necesitas), puedes hacer un repositorio de git con solo mytheme y myplugins directorios y unirlos simbólicamente desde la instalación de WordPress.

---

MDCore escribió:

hacer un commit a, por ejemplo, mytheme se incrementa el número de revisión de miplugin

Tenga en cuenta que esto no es una preocupación para Git , si decide colocar ambos directorios en un único repositorio, porque git elimina por completo el concepto de aumentar monótonamente los números de revisión de cualquier forma.

El único criterio de qué cosas juntar en un único repositorio en git es si constituye una sola unidad, es decir. en su caso, si hay cambios en los que no tiene sentido mirar las ediciones en cada directorio de forma aislada. Si tiene cambios donde necesita editar archivos en ambos directorios a la vez y las ediciones van juntas, deben ser un repositorio. Si no, entonces no los englobes juntos.

Git realmente quiere que use repositorios separados para entidades separadas.

submodules

submódulos no abordan el deseo de mantener las dos directorios en un repositorio, ya que en realidad cumplir tener un repositorio separado para cada directorio, que luego se reunió en otra repositorio utilizando submódulos. Peor aún, dado que los directorios dentro de la instalación de WordPress no son subdirectorios directos del mismo directorio y también forman parte de una jerarquía con muchos otros archivos, usar los repositorios por directorio como submódulos en un repositorio unificado no ofrecería ningún beneficio, porque el el repositorio no reflejaría ningún caso/necesidad de uso.

Answer 3

No puede verificar un solo directorio de un repositorio porque todo el repositorio es manejado por la única carpeta .git en la raíz del proyecto en lugar de la miríada de directorios .svn de subversion.

El problema con el trabajo en plugins en un único repositorio es que hacer una confirmación a, por ejemplo, mytheme se incrementará el número de revisión para miplugin, por lo que incluso en la subversión es mejor utilizar repositorios separados.

El paradigma de la subversión de los sub-proyectos es svn:externals que se traduce tanto a submodules en Git (pero no exactamente en caso de que haya utilizado svn:. Externo antes)

Answer 4

En realidad, "estrecho" o "parcial" o Los checkouts "dispersos" están en desarrollo actual y pesado para Git. Tenga en cuenta que aún tendrá el repositorio completo en .git. Por lo tanto, las otras dos publicaciones son actuales para el estado actual de Git, pero parece, como si pudiéramos hacer revisiones dispersas eventualmente. Checkout the mailing lists si está interesado en más detalles, están cambiando rápidamente.

Answer 5

Como su edición lo señala, puede usar dos ramas separadas para almacenar los dos directorios separados. Esto los mantiene a los dos en el mismo repositorio, pero aún no puede tener confirmaciones que abarquen ambos árboles de directorios. Si tiene un cambio en uno que requiere un cambio en el otro, tendrá que hacer eso como dos confirmaciones separadas, y abre la posibilidad de que un par de comprobaciones de los dos directorios se desincronicen.

Si desea tratar el par de directorios como una unidad, puede usar 'wordpress/wp-content' como la raíz de su repositorio y usar el archivo .gitignore en el nivel superior para ignorar todo menos los dos subdirectorios de interesar. Esta es probablemente la solución más razonable en este punto.

Aparentemente, se han producido raciones dispersas durante dos años, pero todavía no hay indicios de ellas en el repositorio de desarrollo de git, ni indicios de que los cambios necesarios lleguen allí. No contaría con ellos.

Answer 6

Una cosa que no me gusta de los checkes dispersos, es que si quiere sacar un subdirectorio que tiene unos pocos directorios, su estructura de directorio debe contener todos los directorios que lo conducen.

Cómo soluciono esto es clonar el repositorio en un lugar que no es mi área de trabajo y luego crear un enlace simbólico en mi directorio del espacio de trabajo al subdirectorio en el repositorio. Git funciona así bastante bien porque cosas como el estado de git mostrará los archivos de cambio relativos a su directorio de trabajo actual.