workflow git-svn per la fusione utilizzando svn.pushmergeinfo

Question

Qual è il corretto flusso di lavoro per la fusione svn rami monitorati tramite git-svn. Ho letto un po 'la git-svn svn.pushmergeinfo chiave di configurazione e le avvertenze sono:

Da http://www.kernel.org/pub/software/scm/git/docs/git-svn.html:

chiave di configurazione: svn.pushmergeinfo

Questa opzione causerà git -svn a tentativo di popolare automaticamente la proprietà svn: mergeinfo proprietà nel repository SVN quando possibile. Attualmente, questo può essere fatto solo quando dcommitting non fast-forward si fonde in cui tutti i genitori, ma il primo sono già stati spinti in SVN.

Quindi il mio flusso di lavoro normale è:

Supponendo che ho uno SVN ramo ^/rami/feature_branch

# Ensure git-svn is configured to populate svn:mergeinfo 
git config --global svn.pushmergeinfo true 

# Update my local svn remotes state 
git svn fetch 

# Track a local branch against a remote SVN backed ^/branches/feature_branch 
git checkout -b local_feature_branch remotes/feature_branch 

# Modify files and commit to local git repo 
git commit -a -m "changes" 
# Push changes to SVN branch ^/branches/feature_branch 
git svn dcommit 

Poi, per unire fino ^/tronco nella mia local_feature_branch presumo che faccio qualcosa di simile ?

# Sync to the latest SVN 
git svn fetch 
# Rebase "master" which is tracking the remote SVN ^/trunk 
git checkout master 
git svn rebase 

# Checkout the local_feature_branch 
git checkout local_feature_branch 

# Merge "master" into "local_feature" which is tracking ^/trunk 
git merge --squash master 
git commit -m "merge master which is tracking SVN ^/trunk" 

# Dry run the dcommit to SVN which should include svn:mergeinfo property changes 
git svn dcommit --dry-run 

# Commit merge to trunk 
git svn dcommit 

Answer 1

Utilizzando merge --squash e svn.pushmergeinfo insieme non ha molto senso. Con unione --squash, il risultante commit non sarà un'unione commit, quindi una successiva dcommit non crea alcun mergeinfo.

so che (per lo più anziani) le discussioni qui su StackOverflow suggeriscono usando --squash, ma io credo che sia in gran parte una reliquia del passato. Ho usato git-svn per gestire il repository svn della nostra azienda da quasi un anno, e finora ha funzionato benissimo con il seguente flusso di lavoro:

Mi assicuro sempre prima di unire che sono aggiornato e, giusto per essere sicuri, che io non ho alcun commit non sincronizzati locali:

# On local_feature_branch 
# Update from SVN 
git svn fetch && git svn rebase -l 

# push pending commits 
git svn dcommit 

poi faccio un 'vero' unire, utilizzando il ramo "a distanza" SVN come sorgente. Ciò consente di risparmiare rami e l'aggiornamento di commutazione, e assicura che il ramo in entrata non ha commit non sincronizzati locali:

# Create a real, non-forward merge commit 
git merge --no-ff svn/trunk 

# ... and push it to SVN, including mergeinfo 
git svn dcommit 

Inoltre, in questo modo l'unione viene correttamente registrata nella storia locale, in modo da unioni successive non avranno per far fronte a conflitti precedentemente risolti. Con --squash ti ritroveresti con quelli in ogni fusione.

Si noti tuttavia che c'è un problema aperto con mergeinfo quando si esegue il merging da local_feature_branch a trunk (ovvero reintegrazione in svn-speak): Git-SVN with svn.pushmergeinfo: how to avoid self-referencing mergeinfo lines. Questo è successo raramente nel nostro repository, ma finora non ha causato alcun problema per me.