2016-05-17 23 views
19

Ho tre pronti contro termine - i nomi cambiati per chiarezza:Unione di modifiche sottostruttura - fatale: Percorso non valido '' somefile_BASE_20704.cs

SharedStuff, ProjectA e ProjectB

Entrambi i progetti utilizzano git-sottostruttura per mantenere una copia locale di SharedStuff. Entrambi hanno apportato modifiche locali che sto tentando di unire centralmente, testare, quindi unirmi nuovamente a ciascuna di esse.

ho eseguito questo sul repo ProjectA:

git subtree split --prefix=SharedStuff -b SharedStuff_from_ProjectA --rejoin

... poi spinto che al SharedStuff pronti contro termine, ha deliberato alcuni conflitti semplici, fuse in su.

Ora ho eseguito questo sul repo ProjectB:

git subtree split --prefix=platform/SharedStuff -b SharedStuff_from_Project_B --rejoin

... e ancora una volta spinto che al SharedStuff pronti contro termine in una nuova filiale. . Il problema si verifica quando sto cercando di unire le modifiche in

Nel caso attuale, posso passare al ramo SharedStuff_from_Project_B, quindi git merge master - ma ho subito ottenere tutti i file modificati elencati come add/aggiungo conflitti. Quando eseguo git mergetool, ognuno ha un errore come questo:

Merging: 
somefile.xyz 

Normal merge conflict for 'somefile.xyz': 
    {local}: created file 
    {remote}: created file 
fatal: invalid path './somefile.xyz_BASE_20704.cs' 

(Naturalmente, se provo il contrario - per unire SharedStuff_from_Project_B in master - ottengo lo stesso tipo di conflitti, semplicemente invertite ancora. aggiungi/aggiungi).

La mia ipotesi è che qualcosa potrebbe essere sbagliato nella cronologia di ProjectB, causando l'apparenza di aggiungere/aggiungere. Non sono sicuro di come diagnosticare ulteriormente questo, però - cosa posso fare?

Edit: c'era un precedente sottostruttura "ricongiungersi" impegnarsi in ProjectB, ma le modifiche non sono state fuse in SharedStuff a quel punto sembra. Tuttavia, la ripetizione di git subtree split con --ignore-joins produce lo stesso problema: un sacco di conflitti di unione add/add, nonostante la cronologia di quel ramo di sottostruttura diviso che risale a quando lo SharedStuff è stato inserito per la prima volta in ProjectB. :(

Edit: Anche git merge-base tra la sottostruttura scissione dal ProjectB e master su SharedStuff non dà alcun risultato io non sono sicuro di come questo è venuto per essere o come risolvere

+0

Qui andiamo, numero 3 ... –

risposta

1

che faccio.? non so cosa abbia causato questo, tuttavia, ecco come ho risolto il problema: voglio ancora una risposta migliore!

Entrambi i rami "condivisi" il master attuale su SharedStuff e la copia scissione da ProjectB aveva lo stesso si impegna nella loro storia lontana - beh, lo stesso cambia con lo stesso tree SHA internamente, ma diversi commit SHA. Questo perché, in qualche modo, il ramo ProjectB ha avuto un commit iniziale molto diverso diverso da SharedStuff.

Fintantoché non ci sono stati commit comuni (con gli stessi SHA) nella cronologia, l'unione, la reimpostazione e così via non saranno in grado di trovare un terreno comune e si supporrà che i file siano stati aggiunti in entrambe le cronologie.

La soluzione: trovare due impegna presto nella storia con la stessa tree SHA (vale a dire esattamente lo stesso contenuto del file), e impegnarsi informazioni - messaggio, autore, ecc - e manualmente 'sovrascrittura' il genitore di che impegnarsi in ProjectB ' s ramo diviso al genitore nel master di SharedStuff.

Ho fatto questo utilizzando un innesto: Setting git parent pointer to a different parent

  1. Scrivi una nuova linea di .git/info/grafts, fondamentalmente wrong-parent right-parent
  2. Passare al ramo - scoprire PowerShell echo utilizzato un formato di caratteri a 16 bit, salvare nuovamente con sublime Text e passare di nuovo;)
  3. Run git filter-branch right-parent..HEAD sul ramo per sigillare l'affare
  4. verificare che sia tutto unificabili

La prossima divertente sfida sarà vedere come questa versione si ricongiunge in ProjectB; aggiornerà quando ciò è fatto ..

Sarei ancora davvero felice di una vera risposta a questo - questo è davvero hacky!

+0

Correzione rapida: la linea di innesto dovrebbe essere effettivamente "figlio di genitore di genitore errato". Ma non voglio ancora ricorrere a questo .. –