Riparazione del repository git-svn dopo la revisione storica di Subversion modificata

Question

Io uso git-svn per mantenere un clone di un repository Subversion condiviso. Recentemente qualcuno ha modificato il messaggio di commit di una revisione (a lathis SO question) dopo che avevo la revisione git svn fetch. Come posso correggere il mio clone Git per avere il messaggio di commit corretto?

Mi aspettavo git svn reset seguito da git svn fetch per recuperare questo commit e aggiornare le cose, lasciandomi solo bisogno di sistemare le mie filiali locali, ma in realtà non sembra che faccia nulla; lo git svn fetch non recupera i commit su cui sono stato resettato.

(Sì credo che cambiare il messaggio di commit era una cattiva idea, ma non è qualcosa che ho il controllo su.)

Aggiornamento: ho provato il processo che sleske suggerito (in realtà, avevo provato prima di fare la domanda, ma ho appena provato di nuovo nel caso), ma senza fortuna. Ottengo uscita come di seguito:

me_and@centos ~/code ((358a2dd...)) Fri 16 Jan 15:31:27 
$ git svn reset -p 55102 
r55094 = 25d126219f7eeddfc7d0842704c7efcc0443dd70  (refs/remotes/origin/branchname) 

me_and@centos ~/code ((358a2dd...)) Fri 16 Jan 15:33:06 
$ git svn fetch 

me_and@centos ~/code ((358a2dd...)) Fri 16 Jan 15:33:08 
$ 

Non c'è alcuna uscita dal git svn fetch (o non v'è se v'è stato impegna dall'ultima volta che ho fatto funzionare, ma è solo andare a prendere i nuovi commit, non refetching quelli vecchi), e in particolare non c'è il messaggio rereading come nell'esempio di sleske.

Nel caso sia rilevante, sto usando Git v2.0.4.

Update 2: Leggermente redatto .git/config di seguito:

[core] 
    repositoryformatversion = 0 
    filemode = true 
    bare = false 
    logallrefupdates = true 
[svn-remote "svn"] 
    url = http://server/repos/repo 
    fetch = trunk:refs/remotes/origin/trunk 
    branches = branches/*:refs/remotes/origin/* 
    tags = tags/v10/*:refs/remotes/origin/tags/* 
    tags = tags/v11/*:refs/remotes/origin/tags/* 
    tags = tags/v12/*:refs/remotes/origin/tags/* 
    tags = tags/v13/*:refs/remotes/origin/tags/* 

non posterò l'uscita piena di git branch -avv, perché c'è un sacco di esso, ma è lì che si fa veramente interessante, così ho' Pubblicherò un elenco di tutto ciò che ho fatto:

1. Avevo una verifica di un ramo diverso dal ramo con l'errore. L'esecuzione di git svn reset non ha fatto alcuna differenza: remotes/origin/branchname ha continuato a indicare un commit più recente. Non sorprende che lo git svn fetch non abbia fatto nulla.

2. Ho controllato remotes/origin/branchname e ho eseguito di nuovo git svn reset. Questo ha funzionato: remotes/origin/branchname puntato sul padre del commit duff.

3. Ho eseguito git svn fetch. Questo non ha fatto assolutamente nulla: nessun commit è stato prelevato e remotes/origin/branchname non si è mosso.

4. Ho creato un paio di commit fittizi su quel ramo nel repository Subversion (uno ha aggiunto un file vuoto, il successivo lo ha eliminato di nuovo), quindi ha eseguito git svn fetch again.

   Ecco dove diventa davvero strano: il commit di duff non è stato ripetuto. Invece, il recupero è iniziato al commit in cui ho aggiunto il file fittizio, ha riportato un "errore di indice" nel processo. Il rendering git show sul commit che ha aggiunto il file fittizio lo mostra con tutte le differenze tra il commit reimpostato e il dummy commettere.

   Ora, in esecuzione git log --graph --decorate --pretty=oneline --abbrev-commit HEAD origin/branchname assomiglia a questo:

   * 7b12bbc (origin/branchname) Remove dummy file 
   * 730c2ab Add dummy file # But `git show 730c2ab` includes the diffs between b89af06 and 93920f9 as well 
   | * 93920f9 (HEAD) Uninteresting commit 
   | * 91c7163 Uninteresting commit 
   | * ce51022 Commit with the changed commit message 
   |/ 
   * b89af06 Uninteresting commit 
   

   Nota che, oltre HEAD, ora c'è niente indicando alcuni dei commit su questo ramo.

sto rapidamente arrivando alla conclusione che almeno una parte di questo comportamento è semplicemente un bug nel git svn. Certamente quello che ho visto al punto 4 sopra non è qualcosa che dovrebbe accadere, almeno per mia comprensione.

Answer 1

git svn reset è davvero il modo giusto per farlo. Supponendo revisione SVN 4711 è stato cambiato, i passaggi sono:

1) Eliminare il revisione SVN cambiato (e tutto quello che segue):

$ git svn reset -p 4711 
r1 = 18614es3df44c30da07 (refs/remotes/git-svn) 

2) Fetch la revisione cambiato:

$ git svn fetch 
rereading 18614es3df44c30da07 
     A  trunk/a 
r4711 = 8dfb7d0758dbbc1d06004 (refs/remotes/git-svn) 
     A  trunk/b 
r4712 = e7337af3743e48c90ef3fa09906378b95997314c (refs/remotes/git-svn) 
[...] 

3) Ora i dati di git-svn vengono riparati. Devi ancora riparare le tue filiali locali. Ad esempio, se maestro tiene traccia del tronco SVN, eseguire:

git rebase remotes/git-svn 

(dove "telecomandi/git-svn" è il ramo remoto di monitoraggio creato da git svn - potrebbe avere un nome diverso).

Questo è spiegato abbastanza bene nello git svn manpage, nella sezione sul sottocomando "reset".

Answer 2

git svn reset <revision-number> funziona, ma è necessario specificare un numero di revisione precedente al commit incriminato e quindi rifare il numero git svn fetch. Diciamo che il commit modificato è R.100, sarà necessario git svn reset 99 quindi fare git svn fetch, solo che recupererà nuovamente il nuovo commit modificato.

Come del caso di 730c2ab contenenti schiacciata di b89af06-93920f9:

* 7b12bbc (origin/branchname) Remove dummy file 
* 730c2ab Add dummy file # But `git show 730c2ab` includes the diffs 
    between b89af06 and 93920f9 as well 
| * 93920f9 (HEAD) Uninteresting commit 
| * 91c7163 Uninteresting commit 
| * ce51022 Commit with the changed commit message 
|/ 
* b89af06 Uninteresting commit 

git-svn occasionalmente che il commit che è cambiato. Non sono sicuro delle specifiche, ma di tanto in tanto mi sono imbattuto quando la copia di lavoro di un particolare commit sulla svn è cambiata dall'ultima raccolta, git svn comprimerà le modifiche insieme al prossimo commit sul prossimo recupero. Per risolvere questo problema, è possibile ripristinare il commit precedente, e ri-prendere di nuovo

EDIT:

non ho notato in precedenza che ce51022 è già staccata dal ramo principale. SVN esegue la ramificazione in modo diverso e git-svn non sarà in grado di mantenere i rami git su svn. Ciò comporterà anche il commit schiacciato quando esegui git svn dcommit o git svn fetch/rebase