2009-06-01 16 views
7

mio tipico flusso di lavoro git-svn è:Perché git-svn dcommit lascia permessi duplicati nel mio repository git? Posso smettere di farlo?

git checkout -b story-xyz 
git commit -a -m "work" 
git commit -a -m "more work" 
git checkout master 
git svn fetch 
git merge remotes/trunk 
git checkout story-xyz 
git rebase master (sometimes with -i) 
git checkout master 
git merge story-xyz 

A questo punto io ho la mia master e story-xyz rami che punta alla stessa commettere, una o più commette davanti remotes/trunk. Tutto dal remotes/trunk è in una storia lineare.

last svn commit [remotes/trunk] <--- work <--- more work [master, story-xyz] 

Ho poi corro

git svn dcommit 

mi aspettavo di vedere i commit tra remotes/trunk e master revisioni Subversion diventati, e alla fine con una sola storia lineare con remotes/trunk, master e story-xyz tutto indicando l'ultimo revisione, in questo modo:

last svn commit <--- work <--- more work [master, story-xyz, remotes/trunk] 

Le mie revisioni di Subversion vanno in bene, ma finisco con una struttura a due rami. La radice comune del ramo è la testa di Subversion prima che io commettessi. Entrambi i rami contengono la stessa serie di commit, nel senso che contengono le stesse differenze. Il ramo story-xyz è a capo di un ramo, remotes/trunk e master all'altra:

last svn commit <--- work <--- more work [master, remotes/trunk] 
        | 
        \- work <--- more work [story-xyz] 

Il git commit che avevo prima di eseguire git svn dcommit sono sul ramo inferiore (story-xyz), con il mio git commit messaggi, git nome utente e indirizzo email, e git commit timestamps. I commit sul ramo superiore sono nuovi commit di git. Usano il mio nome utente di Subversion, il timestamp quando ho eseguito il dcommit e ai messaggi di commit è stato aggiunto il campo git-svn-id.

Questo è tutto OK, e posso continuare a lavorare. Il problema è che guardo in gitk e vedo quello che sembra un ramo non occupato story-xyz. È piuttosto difficile capire la differenza tra un ramo di una storia che ho fuso con lo master e uno che non ho. Il modo più ovvio per individuarlo sono i messaggi di commit duplicati. Potrei cancellare il ramo story-xyz, ma sembra che io non stia usando git correttamente e ho perso parte della mia storia.

Mi manca qualcosa che si fermerebbe git-svn da questo? O è solo uno dei modi in cui interagire con Subversion diluisce la potenza e la libertà di git?

risposta

4

Non penso che ti manchi davvero niente. Potresti fare un lavoro inutile, però. In questo caso, hai due riferimenti al commit "more work" e stai chiedendo a git-svn di spostarne uno. L'altro rimane ancora dov'è.

Non è necessario il ramo master. Git-svn non si preoccupa di quale ramo stai derubando. IIRC, usa il primo svn-remote che può trovare tra gli antenati del commit corrente.

offro un'altra versione del flusso di lavoro:

git checkout -b story-xyz remotes/trunk 
git commit -a -m "work" 
git commit -a -m "more work" 
git svn fetch 
git rebase remotes/trunk (with -i, perhaps) 
git svn dcommit 

Questo dovrebbe dare un albero senza il ramo più. Tuttavia, devi fare attenzione con le fusioni veloci.

+0

Grazie, ci proverò oggi.Sembra che questo rimuoverà completamente la necessità del master, quindi intendi che la cronologia dei telecomandi/trunk sia ora la nostra "linea principale" della storia? –

+1

La cronologia dei telecomandi/trunk è la 'linea principale' anche nel tuo caso. Guarda il tuo ultimo grafico. La cronologia del master è la stessa della cronologia di telecomandi/trunk. Entrambi sono ugualmente validi come "linea principale" - anche più remoti, perché è la linea principale _shared_. Non è necessario eliminare completamente il master. Puoi lasciarlo sospeso in qualche punto precedente della storia. Quindi se hai bisogno di farlo per es. un commit, puoi eseguire il checkout di master e svn rebase al giorno presente. –

+0

Sì, questo ha senso. Suppongo di essere troppo legato all'idea che il "maestro" sia così speciale da doverlo tenere aggiornato e aggiornato. Non ho ancora avuto la possibilità di provare il tuo flusso di lavoro, ma se funziona come previsto, accetterò la risposta. –

Problemi correlati