remote - ¿Dos repositorios git en un directorio?

git push example (9)

¿Es posible tener 2 repositorios de git en un directorio? Yo pensaría que no, pero pensé en preguntar. Básicamente, me gustaría verificar en mis archivos de configuración del directorio de inicio (por ejemplo, .emacs) que deberían ser comunes en todas las máquinas en las que trabajo, pero tengo un segundo repositorio de archivos locales (por ejemplo, .emacs.local), que contiene configuraciones específicas de la máquina. La única forma en que puedo pensar para hacer eso es tener la configuración local en un subdirectorio e ignorar ese subdirectorio del repositorio principal de git. ¿Alguna otra idea?

Descargo de responsabilidad: esto no es publicidad. Soy el desarrollador de la biblioteca proporcionada.

Creé una extensión git para manejar casos en los que quiera mezclar múltiples repositorios en una sola carpeta. La ventaja de lib es realizar un seguimiento de los repositorios y conflictos de archivos. puedes encontrarlo en github . También hay 2 repositorios de ejemplo para probarlo.

Echa un vistazo al submódulo de git .

Los submódulos permiten que los repositorios extranjeros se incrusten dentro de un subdirectorio dedicado del árbol fuente, siempre apuntando a una confirmación particular.

Es posible usando la variable GIT_DIR pero tiene muchas advertencias si no sabes lo que estás haciendo.

Este artículo cubre esto relativamente bien:

http://git-scm.com/blog/2010/04/11/environment.html

Básicamente, si trabajas desde la línea de comandos, esto es más simple de lo que imaginas. Supongamos que quiere 2 git repos:

.gitone .gittwo

Puede configurarlos de esta manera:

git init . mv .git .gitone git init . mv .git .gittwo

Puedes agregar un archivo y comprometerlo solo a uno así:

git --git-dir=.gitone add test.txt git --git-dir=.gitone commit -m "Test"

Entonces las opciones para git son lo primero, luego el comando, luego las opciones del comando git. Fácilmente podrías alias un comando git como:

#!/bin/sh alias gitone=''git --git-dir=.gitone'' alias gittwo=''git --git-dir=.gittwo''

Entonces puedes comprometerte con uno o el otro con menos tipeo, como gitone commit -m "blah" .

Lo que parece ser más complicado es ignorarlo. Dado que .gitignore normalmente se encuentra en la raíz del proyecto, necesitaría encontrar una forma de cambiar esto sin cambiar la raíz completa. O bien, podría usar .git / info / exclude, pero no se comprometerá o presionará todo lo que ignore, lo que podría arruinar a otros usuarios. Otros que usen cualquiera de los dos repositorios pueden presionar un .gitignore, lo que puede causar conflictos. No es claro para mí la mejor manera de resolver estos problemas.

Si prefiere herramientas de GUI como TortoiseGit, también tendrá algunos desafíos. Podría escribir un pequeño script que cambie el nombre de .gitone o .gittwo a .git temporalmente para que se cumplan las suposiciones de estas herramientas.

La otra opción es crear carpetas separadas y crear enlaces duros simbólicos de una carpeta a otra.

Por ejemplo, si hay repositorios:

Repo1 / FolderA
Repo1 / FolderB

Repo2 / FolderC

Puede FolderA simbólicamente las carpetas FolderA y FolderB del Repo1 al Repo2. Para Windows, el comando para ejecutar en Repo1 sería:

User@Repo1$ mklink /J FullPath/Repo2/FolderA FullPath/Repo1/FolderA User@Repo1$ mklink /J FullPath/Repo2/FolderB FullPath/Repo1/FolderB User@Repo1$ printf "/FolderA/*/n/FolderB/*/n" >> .gitignore

Para los archivos en los repositorios principales, deberá .gitignore simbólicamente cada uno de ellos, y agregarlos al repositorio .gitignore para evitar el ruido, a menos que lo desee.

RichiH escribió una herramienta llamada vcsh que es una herramienta para administrar archivos punto usando los repositorios falsos falsos de git para poner más de un directorio de trabajo en $ HOME. Nada que ver con csh AFAIK.

Sin embargo, si tuvieras varios directorios, una alternativa a los git-submódulos (que son una molestia en las mejores circunstancias y este uso de ejemplo no es la mejor de las circunstancias) es gitslave que deja los repos esclavos controlados en la punta de un sucursal en todo momento y no requiere el proceso de tres pasos para hacer un cambio en el repositorio subsidiario (pago en la sucursal correcta, hacer y comprometer el cambio, luego ingresar al superproyecto y comprometer el nuevo compromiso del submódulo).

Sí, los submódulos son probablemente lo que quieres. Otra opción sería tener su copia de trabajo en un subdirectorio y luego señalar los enlaces simbólicos desde su directorio personal a los archivos de interés.

Si entiendo lo que estás haciendo, puedes manejarlo todo en un repositorio, usando ramas separadas para cada máquina, y una rama que contenga los archivos de configuración comunes del directorio de inicio.

Inicialice el repositorio y asigne los archivos comunes a él, quizás cambiando el nombre de la rama MASTER a Common. Luego, cree una rama separada desde allí para cada máquina con la que trabaje, y envíe archivos específicos de la máquina a esa rama. Cada vez que cambie sus archivos comunes, combine la rama común en cada una de las ramas de la máquina e ingrese en sus otras máquinas (escriba una secuencia de comandos si hay muchas).

Luego, en cada máquina, revise la rama de esa máquina, que también incluirá los archivos de configuración comunes.

mi método preferido es usar un repositorio en un subdirectorio, y usar enlaces simbólicos recursivos:

git clone repo1 cd somerepo git clone repo2 cd repo2 ./build

donde se ve el archivo '' repo / build '':

#!/bin/bash SELF_PATH="$(dirname "$(readlink -f "$0")" )" # get current dir cd .. && git stash && git clean -f -d '''' # remove previous symlinks cp -sR "$SELF_PATH"/* ../. # create recursive symlinks in root

precaución : no use ''git add.''