Sto provando a utilizzare il git mirror GCC, documentato here."Impossibile determinare le informazioni SVN a monte dalla cronologia dell'albero di lavoro"
Qualche tempo fa, ho clonato il repository git:
git clone git://gcc.gnu.org/git/gcc.git
Aggiunto la roba git-svn:
git svn init -Ttrunk --prefix=origin/ svn+ssh://gcc.gnu.org/svn/gcc
E poi git svn rebase
e git svn dcommit
ecc tutto ha funzionato bene.
Alcuni mesi dopo, ho fatto vari lavori di sviluppo sui rami Git locali, e sono venuto a commettere più modifiche a monte SVN:
Update dal miror git:
$ git rebase
Garantire ho l'ultima in assoluto da SVN, ma non funziona:
$ git svn rebase -v Unable to determine upstream SVN information from working tree history
In qualche modo ho infranto i meta dati! Come sopra, penso di averlo fatto git svn fetch
ad un certo punto, per errore, ma non dovrebbe essere dannoso, dovrebbe?
Così, ho cercato di creare un ramo fresco dallo specchio git remote:
$ git branch svntrunk remotes/origin/trunk
$ git checkout svntrunk
$ git svn rebase
Unable to determine upstream SVN information from working tree history
Una ricerca sul web suggerisce che la storia ramo ha in qualche modo discostato da SVN, ma ho controllato git log
ed ogni commettere ha un corrispondente git-svn-id
, che sembra smentire ciò, no?
Quindi, ho provato un nuovo clone da git: //gcc.gnu.org/git/gcc.git, e in quel repository git svn rebase
funziona correttamente. In che modo i due repository, in cui entrambi hanno avuto git rebase
dalla stessa sorgente, hanno una storia diversa? Presumibilmente non possono, e la differenza è nei metadati locali?
Ora, non voglio eliminare il repository in cui ho lavorato (anche se potevo) ed esportare le patch in un altro repository per commettere le sconfitte al punto di avere git-svn in primo luogo. Quindi, come posso ripararlo?
+1, risposta molto bella (da uno dei post del tuo blog, forse ...?). Non sono sicuro che sia direttamente applicabile al problema affrontato (per questo, una soluzione più semplice potrebbe essere più appropriata), ma come procedura applicabile e utilizzabile per l'innesto delle modifiche tra repository in uno stato incoerente, approvo completamente. :) – MrGomez
@MrGomez Spero ci sia una soluzione più semplice. :)) Tutto il resto fallisce, sono abbastanza sicuro che funzionerebbe comunque. –
Quindi, in sostanza, parto da un nuovo repository, inserisco i rami dell'argomento nella cronologia git-svn non rotta al punto giusto tramite un innesto e uso rebase per rendere obsoleto l'innesto. Ho avuto la parte giusta del bastone? – ams