Repositorio de clones GIT en el sistema de archivos local en Windows

Soy un novato completo cuando se trata de GIT. He estado dando mis primeros pasos en los últimos días. Configuré un repositorio en mi computadora portátil, bajé el Trunk de un proyecto SVN (tuve algunos problemas con las sucursales, no los hice funcionar), pero todo parece estar bien allí.

Ahora quiero poder tirar o empujar desde la computadora portátil a mi escritorio principal. La razón es que la computadora portátil es útil en el tren, ya que paso 2 horas al día viajando y puedo hacer un buen trabajo. Pero mi máquina principal en casa es excelente para el desarrollo. Así que quiero poder empujar / tirar de la computadora portátil a la computadora principal cuando llegue a casa. Pensé que la forma más simple de hacer esto sería simplemente tener la carpeta de código compartida en la LAN y hacer:

git clone file://192.168.10.51/code

desafortunadamente esto no parece estar funcionando para mí:

entonces abro un cmd de git bash y escribo el comando anterior, estoy en C: \ code (la carpeta compartida para ambas máquinas) esto es lo que obtengo:

Initialized empty Git repository in C:/code/code/.git/
fatal: 'C:/Program Files (x86)/Git/code' does not appear to be a git repository
fatal: The remote end hung up unexpectedly

¿Cómo puedo compartir el repositorio entre las dos máquinas de la manera más simple?

Habrá otras ubicaciones que serán puntos de almacenamiento oficiales y lugares donde los otros desarrolladores y el servidor CI, etc., se extraerán, esto es solo para que pueda trabajar en el mismo repositorio en dos máquinas.

Según la sugerencia de Sebastian, recibo lo siguiente:

C:\code>git clone --no-hardlinks file://192.168.10.51/code
Initialized empty Git repository in C:/code/code/.git/
fatal: 'C:/Program Files (x86)/Git/code' does not appear to be a git repository
fatal: The remote end hung up unexpectedly

** EDITAR - RESPUESTA **

Gracias a todos los que ayudaron. Intenté mapear un disco y funcionó, así que pensé en volver y volver a intentarlo sin mapear. El resultado final fue:

git clone file://\\\\192.168.0.51\code

Esto funcionó muy bien.

Gracias

Puede especificar la URL del control remoto aplicando la ruta UNC al protocolo del archivo. Esto requiere que uses cuatro barras:

git clone file:////<host>/<share>/<path>

Por ejemplo, si su máquina principal tiene la IP 192.168.10.51 y el nombre de la computadora main, y tiene un recurso compartido codeque es un repositorio git, entonces los dos comandos siguientes deberían funcionar igualmente:

git clone file:////main/code
git clone file:////192.168.10.51/code

Si el repositorio de Git está en un subdirectorio, simplemente agregue la ruta:

git clone file:////main/code/project-repository
git clone file:////192.168.10.51/code/project-repository

$ git clone --no-hardlinks /path/to/repo

El comando anterior utiliza la notación de ruta POSIX para el directorio con su repositorio git. Para Windows es (el directorio C:/path/to/repocontiene el .gitdirectorio):

C:\some\dir\> git clone --local file:///C:/path/to/repo my_project

El repositorio será clonado a C:\some\dir\my_project. Si omite file:///parte, entonces la --localopción está implícita.

la respuesta con el nombre de host no funcionó para mí, pero esto sí:

Archivo git clone: ​​////home/git/repositories/MyProject.git/

Tuve éxito al hacer esto usando file: //, pero con una barra adicional para denotar una ruta absoluta.

git clone file:///cygdrive/c/path/to/repository/

En mi caso, estoy usando Git en Cygwin para Windows, que puedes ver debido a la parte / cygdrive / c en mis rutas. Con algunos ajustes en la ruta, debería funcionar con cualquier instalación de git.

Agregar un control remoto funciona de la misma manera

git remote add remotename file:///cygdrive/c/path/to/repository/

Tal vez asigne el recurso compartido como una unidad de red y luego haga

git clone Z:\

Principalmente solo una suposición; Siempre hago esto usando ssh. Seguir esa sugerencia, por supuesto, significará que necesitará tener esa unidad asignada cada vez que empuje / tire hacia / desde la computadora portátil. No estoy seguro de cómo preparar ssh para trabajar bajo Windows, pero si va a hacer esto mucho, valdría la pena investigarlo.

No estoy seguro de si fue debido a mi versión de git (1.7.2) o qué, pero los enfoques enumerados anteriormente con el nombre del equipo y las opciones de IP no me funcionaban. Un detalle adicional que puede / puede no ser importante es que el repositorio era un repositorio desnudo que había inicializado y enviado desde una máquina diferente.

Intenté clonar project1 como se indicó anteriormente con comandos como:

$ git clone file:////<IP_ADDRESS>/home/user/git/project1
Cloning into project1...
fatal: '//<IP_ADDRESS>/home/user/git/project1' does not appear to be a git repository
fatal: The remote end hung up unexpectedly

y

$ git clone file:////<MACHINE_NAME>/home/user/git/project1
Cloning into project1...
fatal: '//<MACHINE_NAME>/home/user/git/project1' does not appear to be a git repository
fatal: The remote end hung up unexpectedly

Lo que funcionó para mí fue algo más simple:

$ git clone ../git/project1
Cloning into project1...
done.

Nota: a pesar de que el repositorio que se estaba clonando era simple, esto produjo un clon 'normal' con todos los archivos de código / imagen / recurso reales que esperaba (a diferencia de los elementos internos del repositorio git).

Ingrese rutas absolutas o rutas relativas.

Por ejemplo, el primero a continuación usa rutas absolutas:

(Esto es desde el interior de la carpeta que contiene el repositorio y la copia de seguridad como subcarpetas. También recuerde que la carpeta de copia de seguridad no se modifica si ya contiene algo. Y si no está presente, se creará una nueva carpeta)

~/git$ git clone --no-hardlinks ~/git/git_test1/   ~/git/bkp_repos/

Lo siguiente utiliza rutas relativas:

~/git$ git clone --no-hardlinks git_test1/   bkp_repos2/

Si bien la ruta UNC es compatible desde Git 2.21 (febrero de 2019, ver más abajo), Git 2.24 (Q4 2019) permitirá

git clone file://192.168.10.51/code

No más file:////xxx' file://' es suficiente para referirse a una ruta compartida UNC.
Consulte " Error de recuperación de Git con UNC ".

Tenga en cuenta que desde 2016 y el MingW-64 git.exe empaquetado con Git para Windows , se admite una ruta UNC.
(Consulte " ¿Cómo se relacionan entre sí msys, msys2 y MinGW-64? ")

Y con Git 2.21 (febrero de 2019), este soporte se extiende incluso en un shell msys2 (con comillas alrededor de la ruta UNC).

Ver commit 9e9da23 , commit 5440df4 (17 de enero de 2019) por Johannes Schindelin ( dscho) .
Ayudado por: Kim Gybels ( Jeff-G) .
^{(Fusionada por Junio ​​C Hamano -gitster - en commit f5dd919 , 05 feb 2019)}

Antes de Git 2.21, debido a una peculiaridad en el método de Git para generar git-upload-pack, hay un problema al pasar caminos con barras invertidas en ellos: Git forzará la línea de comando a través del shell, que tiene diferentes semánticas de citas en Git para Windows (siendo un MSYS2 programa) que los ejecutables regulares de Win32 como él git.exemismo.

El síntoma es que la primera de las dos barras invertidas en las rutas UNC del formulario \\myserver\folder\repository.git se elimina .

Esto se mitiga ahora:

mingw: argumentos de casos especiales para sh

El tiempo de ejecución de MSYS2 hace todo lo posible para emular la expansión de comodines de línea de comandos y la eliminación de comillas que realizaría el shell Unix de llamada en sistemas Unix.

Esas reglas de comillas de shell de Unix difieren de las reglas de comillas que se aplican a cmd y Powershell de Windows, por lo que es un poco incómodo citar parámetros de línea de comandos correctamente cuando se generan otros procesos.

En particular, git.exepasa argumentos a los subprocesos que no están destinados a ser interpretados como comodines, y si contienen barras invertidas, no deben interpretarse como caracteres de escape, por ejemplo, al pasar rutas de Windows.

Nota: esto es solo un problema cuando se llaman ejecutables de MSYS2, no cuando se llaman ejecutables de MINGW como git.exe. Sin embargo, llamamos a los ejecutables de MSYS2 con frecuencia, especialmente cuando configuramosuse_shell indicador en la estructura child_process.

No hay una manera elegante de determinar si el .exearchivo a ejecutar es un programa MSYS2 o MINGW.
Pero dado que el caso de uso de pasar una línea de comando a través del shell es tan frecuente, debemos solucionar este problema al menos al ejecutarsh.exe .

Vamos a presentar una prueba fea y codificada si argv[0]es "shPresentemos una ", y si se refiere al MSYS2 Bash, para determinar si necesitamos citar los argumentos de manera diferente a lo habitual.

Eso todavía no soluciona el problema por completo, pero al menos es algo.

Por cierto, esto también soluciona el problema donde git clone \\server\repofalló debido a un manejo incorrecto de las barras invertidas al entregar la ruta algit-upload-pack proceso.

Además, debemos tener cuidado de citar no solo espacios en blanco y barras diagonales inversas, sino también corchetes.
Como los alias con frecuencia pasan por el MSYS2 Bash y los alias con frecuencia obtienen parámetros como HEAD@{yesterday}, esto es realmente importante.

Ver t/t5580-clone-push-unc.sh

Después del clon, para mí empujar no estaba funcionando.

Solución: donde se clona el repositorio, abra la carpeta .git y el archivo de configuración.

Para el valor de configuración de URL de origen remoto:

[remote "origin"]
    url = file:///C:/Documentation/git_server/kurmisoftware