Domanda

stiamo usando git-svn per gestire i rami di un repository SVN. Stiamo affrontando il seguente problema: dopo un certo numero di commit da parte dell'utente X nel ramo, l'utente Y vorrebbe usare git-svn per unire le modifiche nel ramo al tronco. Il problema che stiamo riscontrando è che i messaggi di commit per tutte le singole operazioni di unione sembrano fatti dall'utente Y, mentre l'effettiva modifica del ramo è stata effettuata dall'utente X.

Esiste un modo per indicare a git-svn che durante l'unione, utilizzare il messaggio / autore del commit originale per una data modifica piuttosto che la persona che fa l'unione?

È stato utile?

Soluzione

La pagina man git-svn ti consiglia di non usare l'unione . " " Si consiglia di eseguire git-svn fetch and rebase (non pull o merge) " " ;. Detto questo, puoi fare quello che ti piace :-)

Ci sono 2 problemi qui. Il primo è che svn memorizza solo il commiter , non l'autore di una patch come fa git. Quindi quando Y commette le fusioni su trunk, svn registra solo il suo nome, anche se le patch sono state create da X. Questa è una caratteristica sorprendente di git, incredibilmente semplice ma vitale per i progetti open source che attribuivano cambiamenti per l'autore può evitare problemi legali lungo la strada.

In secondo luogo, git non sembra usare le relativamente nuove funzionalità di unione svn. Questa potrebbe essere una cosa temporanea, poiché git viene sviluppato attivamente e vengono continuamente aggiunte nuove funzionalità. Ma per ora, non li usa.

Ho appena provato con git 1.6.0.2 e "perde". informazioni rispetto a fare la stessa operazione con svn merge. In svn 1.5, è stata aggiunta una nuova funzionalità ai metodi di registrazione e annotazione, in modo che svn log -g sul trunk generasse qualcosa del genere per un'unione:

------------------------------------------------------------------------
r5 | Y | 2008-09-24 15:17:12 +0200 (Wed, 24 Sep 2008) | 1 line

Merged release-1.0 into trunk
------------------------------------------------------------------------
r4 | X | 2008-09-24 15:16:13 +0200 (Wed, 24 Sep 2008) | 1 line
Merged via: r5

Return 1
------------------------------------------------------------------------
r3 | X | 2008-09-24 15:15:48 +0200 (Wed, 24 Sep 2008) | 2 lines
Merged via: r5

Create a branch

Qui, Y commette r5, che incorpora le modifiche da X sul ramo nel tronco. Il formato del registro non è poi così eccezionale, ma si manifesta su svn biasimo -g:

       2          Y int main()
       2          Y {
G      4          X   return 1;
       2          Y }

Qui supponendo che Y si impegni solo nel trunk, possiamo vedere che una riga è stata modificata da X (sul ramo) e unita.

Quindi, se stai usando svn 1.5.2, probabilmente stai meglio di fonderti con il client svn reale per ora. Sebbene perderai le informazioni di fusione in git, di solito è abbastanza intelligente da non lamentarti.

Aggiornamento: ho appena provato questo con git 1.7.1 per vedere se ci sono stati dei progressi nel frattempo. La cattiva notizia è che l'unione all'interno di git non popola ancora i valori svn: mergeinfo, quindi git merge seguito da git svn dcommit non imposterà svn: mergeinfo e perderai unire le informazioni se il repository Subversion è la fonte canonica, che probabilmente lo è. La buona notizia è che git svn clone legge in svn: proprietà mergeinfo per costruire una migliore cronologia di unione, quindi se usi svn merge correttamente (richiede l'unione di rami interi) quindi il clone git apparirà corretto agli utenti git.

Altri suggerimenti

Puoi usare gli innesti per insegnare a git le fusioni che non sono indicate nell'oggetto commit in questione.

echo "$merge_sha1 $parent1_sha1 $parent2_sha1" >> .git/info/grafts

Trovare queste informazioni è abbastanza semplice: dato che trova il commit di unione in questione, conosci già $ merge_sha1 e $ parent1_sha1 . Convenzionalmente, il messaggio di commit di tale commit conterrà il numero di revisione SVN del secondo commit parent, che si tradurrà semplicemente nell'ID commit corrispondente:

git svn find-rev r$revnum $branch

Presto, hai tutte e 3 le informazioni che ti servono per creare l'innesto.

Prova a usare le opzioni --add-author-from e --use-log-author per git-svn.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top