Come faccio a dire a git-svn di un ramo remoto creato dopo aver recuperato il repository?

Sto usando git-svn per funzionare contro il repository svn centrale della mia azienda. Di recente abbiamo creato un nuovo ramo di funzionalità nel repository centrale. Come faccio a git ? Quando git branch -r posso solo vedere i rami che esistevano quando ho eseguito il fetch contro il repository svn per inizializzare il mio repository git ?

È ansible aggiungere manualmente il ramo remoto,

 git config --add svn-remote.newbranch.url https://svn/path_to_newbranch/ git config --add svn-remote.newbranch.fetch :refs/remotes/newbranch git svn fetch newbranch [-r] git checkout -b local-newbranch -t newbranch git svn rebase newbranch 

Se vuoi monitorare TUTTI i rami svn remoti, allora la soluzione è semplice come:

 git svn fetch 

Questo preleverà TUTTI i rami remoti che non sono stati ancora recuperati.

Suggerimento extra: se prima hai controllato solo il trunk, e successivamente vuoi monitorare TUTTI i branch, modifica edit .git/config come questo e riesegui git svn fetch :

 [svn-remote "svn"] url = https://svn/path_to_repo_root/ fetch = path_to_trunk:refs/remotes/git-svn branches = path_to_branches/*:refs/remotes/* 

I punti chiave sono url dovrebbe puntare alla radice del repository e i percorsi definiti in fetch e branches dovrebbero essere relativi url .

Se vuoi recuperare solo rami specifici invece di ALL, c’è un bell’esempio in git svn --help :

 [svn-remote "huge-project"] url = http://server.org/svn fetch = trunk/src:refs/remotes/trunk branches = branches/{red,green}/src:refs/remotes/branches/* tags = tags/{1.0,2.0}/src:refs/remotes/tags/* 

Con le versioni precedenti di git-svn , una volta specificati i rami come questo, potresti non essere in grado di ottenere nuovi rami con git svn fetch . Una soluzione alternativa è l’aggiunta di più linee di fetch , come questo:

 [svn-remote "huge-project"] url = http://server.org/svn fetch = trunk/src:refs/remotes/trunk fetch = branches/blue:refs/remotes/branches/blue fetch = branches/yellow:refs/remotes/branches/yellow branches = branches/{red,green}/src:refs/remotes/branches/* 

Un’altra soluzione alternativa di @AndyEstes: modifica .git/svn/.metadata e modifica il valore di branches-maxRev o tags-maxRev in una revisione prima che venissero creati nuovi rami o tag. Una volta fatto questo, avvia git svn fetch per tracciare il nuovo ramo svn remoto.

Sembra che ho solo bisogno di git svn fetch ; in qualche modo mi ero convinto che avrei recuperato l’intero repo invece dei soli cambiamenti.

Forse l’ho incasinato in qualche modo ma ho seguito le istruzioni nella risposta di vjangus e ha quasi funzionato. L’unico problema era che newbranch non sembrava essere ramificato dal bagagliaio. In gitk, era una specie di “fluttuare” tutto da solo; non aveva antenato comune con il tronco.

La soluzione a questo era:

  1. Trova lo SHA1 dell’ultimo commit che si è verificato sul trunk prima della creazione del ramo.
  2. Trova lo SHA1 del primo commit sul nuovo ramo (il messaggio è probabilmente “Creato nuovo ramo, copiato dal trunk @ 12345” o qualcosa del genere)
  3. git diff-tree – non dovrebbe esserci alcun output. Se viene emesso, è ansible che siano stati selezionati i commit errati.
  4. git checkout local-newbranch quindi git rebase . Ciò rebase local-newbranch sul nuovo albero ma i remotes/newbranch saranno ancora disconnessi.
  5. Vai al file .git/refs/remotes/newbranch e modificalo per contenere l’intero SHA1 del nuovo commit (sul nuovobranch newbranch ) che corrisponde al vecchio commit al quale punta attualmente. (O forse usa git-update-ref refs/remotes/newbranch . Grazie inger.)
  6. La prossima volta che git svn dcommit a newbranch , riceverai un sacco di messaggi su di esso aggiornando qualche registro. Questo è normale, penso.

Raccomando di tenere gitk --all tutto aperto per tutto il tempo e aggiornandolo spesso per tenere traccia di ciò che stai facendo. Sono ancora un po ‘nuovo da git e git svn quindi per favore suggerisci miglioramenti a questo metodo.

Non ho trovato alcuna documentazione su questa funzione, ma sembra che la configurazione di git svn supporti più voci di recupero. In questo modo puoi anche aggiungere rami separatamente senza bisogno di aggiungere un’altra voce di repository svn remota alla tua configurazione, né usare i caratteri jolly per ottenere tutti i rami di certe directory.

Supponiamo che il tuo albero SVN sia davvero sgradevole avendo molti rami senza alcuna logica su come si trovano, ad esempio con rami e sottodirectory contenenti più ramificati.

vale a dire

 trunk branches -> branch1 -> sub-dir1 -> branch2 -> branch3 -> sub-dir2 -> branch4 -> sub-dir3 -> branchX < ... hundreds more ...> 

e vuoi semplicemente selezionare alcuni dei rami da includere nel tuo repository git.

È ansible iniziare il repository con il solo trunk senza rami aggiuntivi:

 git svn clone -r 10000:HEAD https://svn.com/MyRepo myrepo --prefix=svn/ --trunk=trunk 

Dopodiché dovresti vedere la seguente configurazione:

 localhost: elhigu$ git config --get-regexp "svn-remote." svn-remote.svn.url https://svn.com/MyRepo svn-remote.svn.fetch trunk:refs/remotes/svn/trunk 

quando mai vuoi recuperare un nuovo ramo da MyRepo puoi semplicemente aggiungere nuove voci di recupero alla configurazione:

 git config --add svn-remote.svn.fetch branches/sub-dir2/branch4:refs/remotes/svn/branches/sub-dir2/branch4 

Oppure puoi modificare la stessa configurazione in .git / config

Per recuperare i nuovi rami dopo averli aggiunti alla configurazione basta eseguire:

 git svn fetch -r 10000:HEAD 

[Modifica] A volte sembra necessario eseguire il recupero con il parametro –all per recuperare i nuovi rami aggiunti:

 git svn fetch --all -r 10000:HEAD 

Una semplificazione della risposta di vjangus:

Se stai usando il layout standard in SVN e hai fatto il solito svn init, git-svn farà le cose di configurazione per te. Appena:

  1. Trova la revisione della copia di ramo in SVN
  2. Scarica questa revisione con git-svn
  3. Crea un nuovo local tracking remoto

Un esempio. L’URL SVN è svn+ssh://gil@svn.myplace.com/repo . Il ramo SVN che sto cercando è newbranch . Il ramo git locale (tracciamento di newbranch remoto) sarà git-newbranch .

Passaggio 1: trova la revisione della copia della filiale

     # svn log --stop-on-copy svn + ssh: //gil@svn.myplace.com/repo/branches/newbranch |  coda -4
     r7802 |  qualcuno |  2014-03-21 18:54:58 +0000 (Ven, 21 Mar 2014)  1 riga

     TESTA ramificata a newbranch
     -------------------------------------------------- ----------------------

Quindi il punto di diramazione in SVN è la revisione 7802.

Passaggio 2: Recupera la revisione

     # git svn fetch -r 7802
     Trovato ansible punto di diramazione: svn + ssh: //gil@svn.myplace.com/repo/trunk => svn + ssh: //gil@svn.myplace.com/repo/branches/newbranch, 7801
     Padre filiale trovato: (ref / remotes / trunk) 8dcf3c5793ff1a8a79dc94d268c91c2bf388894a
     Seguendo genitore con do_switch
     Seguito con successo genitore
     r7802 = 9bbd4194041675ca5c9c6f3917e05ca5654a8a1e (ref / remotes / newbranch)

git-svn ha fatto tutto il lavoro e ora conosce il telecomando:

     # git show-ref |  grep newbranch
     2df23af4733f36f5ad3c14cc1fa582ceeb3edb5c ref / remotes / newbranch

Passaggio 3: crea il tuo nuovo ramo locale per tracciare quello remoto:

     # git checkout -b git-newbranch -t newbranch
     Controllo dei file: 100% (413/413), terminato.
     Branch git-newbranch impostato per tracciare ref ref / remotes / newbranch locali.
     Passato a un nuovo ramo 'git-newbranch'

Invece di affrontare le stranezze di git-svn potresti provare SubGit .

Uno deve installare SubGit nel repository Subversion. Dopo di ciò si può usare il stream di lavoro git standard invece di usare i comandi speciali di git-svn:

  1. Spingendo nuovi commit:

    git-svn:

     $ git commit $ git svn rebase $ git svn dcommit 

    SubGit:

     $ git commit $ git push 
  2. Recupero delle modifiche in entrata

    git-svn:

     $ git svn rebase 

    SubGit:

     $ git pull [--rebase] 
  3. Creare un nuovo ramo:

    git-svn:

     $ git svn branch foo $ git checkout -b foo -t remotes/foo $ git commit $ git svn dcommit 

    SubGit:

     $ git checkout -b foo $ git commit $ git push 

Vedi la documentazione di SubGit per maggiori dettagli.

Per aggiungere alla risposta di vjangus, che mi ha aiutato, ho anche trovato utile aggiungere git innesti per bind i rami al tronco nel punto appropriato – permettendo a git di vedere la cronologia ed eseguire le unioni correttamente.

Questo è semplicemente il caso di aggiungere una riga a .git/info/grafts con gli hash:

   

per esempio.

 378b0ae0902f5c2d2ba230c429a47698810532e5 6c7144991381ce347d4e563e9912465700be0638 

Credito a http://evan-tech.livejournal.com/255341.html

(Vorrei aggiungere questo come commento, ma non ho abbastanza reputazione).

Se non si esegue il check-out con un layout valido, non sarà ansible effettuare il checkout di un ramo remoto.

Questo è ciò che faccio:

 git svn init -s  local_repo cd local_repo git svn fetch ## wait 

Successivamente, puoi passare a un ramo remoto:

 git checkout --track -b branch_name branch_name 

Quindi passerai automaticamente alla tua filiale.