Disclaimer: l'ho testato ora e sembra che funzioni come previsto (presumendo che abbia capito bene, ovviamente). Tuttavia, c'è ancora molto che può andare storto. Provalo assolutamente solo su una copia di lavoro separata del repository del tuo progetto e assicurati di esaminare tutto prima di spostarlo ovunque. Conservare i backup completi delle directory dello stato prima di eseguire questa operazione.
Quindi presumo che tu abbia due repository indipendenti.Il progetto originale (Gephi):
A---B---C---D---E
^HEAD of Gephi
E il progetto, la cui prima revisione sembra identica alla ultima revisione del progetto originale:
E'---V---W---Y---...---Z
^HEAD of your project
(possibilmente con alcuni rami, ma che in realtà non importa . qui)
cosa ti piacerebbe avere (se ho capito bene) è:
A---B---C---D---E---V---W---Y---...---Z
Si potrebbe provare quanto segue. Ancora, fai da solo, albero di lavoro separato e assicurati che sia tutto in ordine prima di inviarlo a qualsiasi repository centrale!
Mentre nella directory del vostro albero di lavoro, prendere le teste e gli oggetti del repository Gephi originale:
git fetch /path/to/original/gephi
Se non è stato clonato il repository Gephi, si potrebbe anche specificare il github URL invece di un percorso del filesystem locale.
Ciò avrà come risultato la seguente situazione nel vostro albero di lavoro corrente:
A---B---C---D---E
^FETCH_HEAD
E'---V---W---Y---...---Z
^HEAD
non abbiamo cambiato molto. Attualmente, i due capi coesistono in modo pacifico e completamente indipendente l'uno dall'altro, ma ora puoi accedere agli oggetti da entrambi i repository e provare a combinarli.
ora vogliamo scartare E'(dovrebbe essere identica a E), e invece fare E il genitore del vostro progetto di primo commit, che è V. A questo scopo, è possibile utilizzare git filter-branch:
git filter-branch -f --parent-filter 'test $GIT_COMMIT = <V> && echo "-p <E>" || cat'
Sostituire <V> e <E> con gli hash di commit rispettivamente di V ed E. Per scoprirli, puoi fare git log per esaminare i commit del tuo progetto e, dal momento che li abbiamo recuperati, git log FETCH_HEAD per esaminare i commit di Gephi.
Ciò collegare efficacemente V direttamente a E.
Questo dovrebbe anche funzionare se si scopre che la testa (vale a dire l'ultimo commit) del repository originale Gephi non è quello che si basa il progetto su significato che ci sono stati nuovi commit in Gephi che non hai (ancora?) preso cura di te. Basta essere sicuri, ancora una volta di sostituire <E> con l'hash del commit su cui si basano le modifiche, non con la testa.
Al contrario, assicurarsi di sostituire <V> con l'hash della prima modifica apportata. Forse il tuo repository non contiene un E 'identico a E, ma il primo commit contiene già delle modifiche rispetto all'originale. Quindi questo primo hash di commit sarà il tuo <V>, anziché quello successivo.
In sintesi entrambe ultimi paragrafi: il comando di cui sopra dovrebbe funzionare anche se la situazione sembra, per esempio, questo:
A---B---C---D---E---F---G---H---I
^ ^FETCH_HEAD
point where your project branched off
V---W---Y---...---Z
^ ^HEAD
first change based on E
Basta fare in modo di utilizzare l'hash che hanno senso in questo contesto commit.
Ho appena provato questo, e sembra funzionare (così ho aggiornato il mio avviso in cima). Vi consiglio assolutamente di provarlo su un albero di lavoro monouso e di effettuare backup completi. È facile ottenere l'istruzione 'filter-branch' errata o mescolare gli hash! –
Se il progetto locale ha più diramazioni, o se ci sono delle unioni nella cronologia, 'git rebase' non è lo strumento giusto perché linearizzerà la cronologia. Usa invece 'filter-branch'. –
Grazie. Era quello che avevo in origine, ma pensavo che rebase avesse la sintassi più semplice. Ho ripristinato le mie modifiche e ora menziona di nuovo il filtro-ramo. –