Reposizionamento di cloni GIT nel file system locale in Windows

Sono un Noob completo quando si tratta di GIT. Ho appena mosso i miei primi passi negli ultimi giorni. Ho installato un repository sul mio laptop, ho rimosso il Trunk da un progetto SVN (ho avuto alcuni problemi con le filiali, non li ho fatti funzionare), ma tutto sembra ok lì.

Ora voglio essere in grado di estrarre o spingere dal laptop al desktop principale. Il motivo è che il laptop è utile sul treno mentre trascorro 2 ore al giorno in viaggio e posso fare un buon lavoro. Ma la mia macchina principale a casa è ottima per lo sviluppo. Quindi voglio essere in grado di spingere / tirare dal laptop al computer principale quando torno a casa. Ho pensato che il modo più semplice per farlo fosse quello di condividere la cartella del codice attraverso la LAN e fare:

git clone file://192.168.10.51/code

sfortunatamente questo non sembra funzionare per me:

quindi apro un git bash cmd e digito il comando sopra, sono in C: \ code (la cartella condivisa per entrambe le macchine) questo è quello che ottengo:

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

Come posso condividere il repository tra le due macchine nel modo più semplice.

Ci saranno altre posizioni che saranno punti di archiviazione ufficiali e luoghi da cui verranno estratti gli altri sviluppatori, server CI, ecc. Questo è solo per poter lavorare sullo stesso repository su due macchine.

Secondo il suggerimento di Sebastian ricevo quanto segue:

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

** MODIFICA - RISPOSTA **

Grazie a tutto ciò che ha aiutato. Ho provato a mappare un'unità e ha funzionato così ho pensato di tornare indietro e riprovare senza mappare. Il risultato finale è stato:

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

Questo ha funzionato alla grande.

Grazie

È possibile specificare l'URL del telecomando applicando il percorso UNC al protocollo file. Ciò richiede di utilizzare quattro barre:

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

Ad esempio, se la tua macchina principale ha l'IP 192.168.10.51 e il nome del computer main, e ha una condivisione denominata codeche a sua volta è un repository git, allora entrambi i seguenti comandi dovrebbero funzionare allo stesso modo:

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

Se il repository Git si trova in una sottodirectory, è sufficiente aggiungere il percorso:

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

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

Il comando sopra usa la notazione del percorso POSIX per la directory con il tuo repository git. Per Windows è (la directory C:/path/to/repocontiene la .gitdirectory):

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

Il repository verrà clonato in C:\some\dir\my_project. Se si omette una file:///parte, l' --localopzione è implicita.

la risposta con il nome host non ha funzionato per me ma questo ha fatto:

file clone git: ////home/git/repositories/MyProject.git/

Sono riuscito a farlo usando file: //, ma con una barra aggiuntiva per indicare un percorso assoluto.

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

Nel mio caso sto usando Git su Cygwin per Windows, che puoi vedere a causa della parte / cygdrive / c nei miei percorsi. Con alcune modifiche al percorso dovrebbe funzionare con qualsiasi installazione git.

L'aggiunta di un telecomando funziona allo stesso modo

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

Forse mappare la condivisione come unità di rete e quindi farlo

git clone Z:\

Principalmente solo un'ipotesi; Faccio sempre queste cose usando ssh. In seguito a questo suggerimento, ovviamente, dovrai mappare quell'unità ogni volta che premi / tira verso / dal laptop. Non sono sicuro di come lavori su ssh per lavorare sotto Windows, ma se lo farai molto, varrebbe la pena investigare.

Non sono sicuro se fosse a causa della mia versione di git (1.7.2) o altro, ma gli approcci sopra elencati usando il nome della macchina e le opzioni IP non funzionavano per me. Un ulteriore dettaglio che può / potrebbe non essere importante è che il repository era un repository nudo che avevo inizializzato e trasferito da un'altra macchina.

Stavo cercando di clonare project1 come consigliato sopra con comandi come:

$ 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

e

$ 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

Ciò che ha funzionato per me è stato qualcosa di più semplice:

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

Nota: anche se il repository da cui è stato clonato era nudo, questo ha prodotto un clone 'normale' con tutti i file di codice / immagine / risorsa che speravo (al contrario degli interni del repository git).

Immettere percorsi assoluti o percorsi relativi.

Ad esempio il primo di seguito utilizza percorsi assoluti:

(questo viene dall'interno della cartella che contiene il repository e il backup come sottocartelle. Ricorda inoltre che la cartella di backup non viene modificata se contiene già qualcosa. E se non è presente, verrà creata una nuova cartella)

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

Quanto segue utilizza percorsi relativi:

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

Mentre il percorso UNC è supportato da Git 2.21 (febbraio 2019, vedi sotto), Git 2.24 (Q4 2019) consentirà

git clone file://192.168.10.51/code

Non più file:////xxx" file://" è sufficiente per fare riferimento a una condivisione percorso UNC.
Vedi " Errore Git Fetch con UNC ".

Nota, dal 2016 e MingW-64 git.exe impacchettato con Git per Windows , è supportato un percorso UNC.
(Vedi "In che modo msys, msys2 e MinGW-64 sono correlati tra loro? ")

E con Git 2.21 (febbraio 2019), questo supporto si estende anche in una shell msys2 (con virgolette attorno al percorso UNC).

Vedi commit 9e9da23 , commit 5440df4 (17 gennaio 2019) di Johannes Schindelin ( dscho) .
Aiutato da: Kim Gybels ( Jeff-G) .
^{(Unito da Junio ​​C Hamano - gitster- in commit f5dd919 , 05 feb 2019)}

Prima di Git 2.21, a causa di una stranezza nel metodo di Git di spawn git-upload-pack, c'è un problema quando si passano percorsi con barre rovesciate: Git forzerà la riga di comando attraverso la shell, che ha una semantica di quotazione diversa in Git per Windows (essendo un MSYS2 programma) rispetto ai normali eseguibili Win32 comegit.exe stesso.

Il sintomo è che la prima delle due barre rovesciate nei percorsi UNC del modulo \\myserver\folder\repository.gitviene rimossa .

Questo è mitigato ora:

mingw: argomenti di casi speciali a sh

Il runtime MSYS2 fa del suo meglio per emulare l'espansione jolly della riga di comando e declassare che verrebbe eseguita dalla shell Unix chiamante sui sistemi Unix.

Queste regole di quotazione della shell Unix differiscono dalle regole di quotazione che si applicano a cmd di Windows e Powershell, rendendo un po 'scomodo citare correttamente i parametri della riga di comando quando si generano altri processi.

In particolare, git.exepassa argomenti ai sottoprocessi che non devono essere interpretati come caratteri jolly e, se contengono barre rovesciate, questi non devono essere interpretati come caratteri di escape, ad esempio quando si passano percorsi di Windows.

Nota: questo è solo un problema quando si chiamano eseguibili MSYS2, non quando si chiamano eseguibili MINGW come git.exe. Tuttavia, chiamiamo eseguibili MSYS2 frequentemente, in particolare quando si imposta il use_shellflag nella struttura child_process.

Non esiste un modo elegante per determinare se il .exefile da eseguire è un programma MSYS2 o MINGW.
Ma poiché il caso d'uso del passaggio di una riga di comando attraverso la shell è così diffuso, dobbiamo risolvere questo problema almeno durante l'esecuzionesh.exe .

Introduciamo un brutto test codificato se argv[0]è "sh " e se si riferisce a MSYS2 Bash, per determinare se dobbiamo citare gli argomenti in modo diverso dal solito.

Ciò non risolve ancora completamente il problema, ma almeno è qualcosa.

Per inciso, questo risolve anche il problema in caso git clone \\server\repodi errore a causa di una gestione errata delle barre rovesciate durante la consegna del percorso algit-upload-pack processo.

Inoltre, dobbiamo fare attenzione a citare non solo spazi bianchi e barre rovesciate, ma anche parentesi graffe.
Dato che gli alias passano spesso attraverso il Bash MSYS2 e che spesso gli alias ottengono parametri come HEAD@{yesterday}questo, questo è davvero importante.

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

Dopo il clone, per me la spinta non funzionava.

Soluzione: dove viene clonato il repository, aprire la cartella .git e il file di configurazione.

Per il valore impostato dell'URL di origine remota:

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