git-svn: réinitialisation de suivi pour le master

Question

Je suis à l'aide d' git-svn de travailler avec un dépôt SVN. Mon copies de travail ont été créés à l'aide de git svn clone -s , de sorte que ma copie de travail suit le répertoire par défaut de schéma pour le SVN (trunk, tags, branches).

Récemment j'ai travaillé sur une branche qui a été créé à l'aide d' http://foo.bar/myproject et extrait à l'aide de . J'avais besoin de travailler à partir de plusieurs endroits, donc à partir de la branche I git-svn branch myremotebranch-ed fichiers pour le dépôt SVN assez régulièrement.

Après avoir terminé mes modifications, j'ai basculé vers le maître et exécuté une opération de fusion, commis de la fusion, et a essayé de dcommit la réussite de la fusion du coffre à distance.

Il semble que, après la fusion et le suivi à distance pour le maître a passé à la direction générale, j'ai été travailler sur:

git checkout --track -b mybranch myremotebranch

Est il possible que je peux mettre à jour le maître, de sorte qu'il est suit git-svn dcommit comme avant la fusion?

J'utilise git 1.7.0.5, si c'est de l'aide.

Il serait utile si vous pouviez aussi expliquer pourquoi ce qui s'est passé, afin que je puisse éviter le problème de se produire à nouveau. Merci!

Edit:

Voici mon actuel # git checkout master # git merge mybranch ... (successful) # git add . # git commit -m '...' # git svn dcommit Committing to http://foo.bar/myproject/branches/myremotebranch ... # :

remotes/trunk

Il semble donc que le tronc est de montrer la bonne place. Cependant, le passage à la branche puis retour vers le maître n'aide pas; .git/config dans le maître essaie toujours de pousser à l' [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true autocrlf = false [svn-remote "svn"] url = http://foo.bar/myproject fetch = trunk:refs/remotes/trunk branches = branches/*:refs/remotes/* tags = tags/*:refs/remotes/tags/* [branch "mybranch"] remote = . merge = refs/remotes/myremotebranch .

Answer 1

Quand il n'y a pas de changements sur le tronc, git ne une avance rapide de fusion et définit simplement le "maître" de la branche de la validation de votre succursale. Git-svn ne sait pas comment s'engager d'avance rapide, fusionne avec le tronc, en fait, il pense que "maître" est maintenant pointant vers la branche svn.

Pour contourner ce problème, utilisez git merge --no-ff lors de la fusion. Cela va forcer git pour créer une fusion de commettre, qui peut ensuite être dcommitted à svn.

Answer 2

Si vous git svn rebase après être repassé à maîtriser et à utiliser --squash vous pouvez éviter cela.

# git checkout master
# git svn rebase   //(<--the missing step)
# git merge --squash mybranch // (<-- doesn't commit, more like an svn merge would do)
... (successful)
# git add . 
# git commit -m '...' 
# git svn dcommit
Committing to http://foo.bar/myproject/trunk...
#

Pour résoudre l'état actuel (c'est à dire à votre maître est pointant vers une branche SVN)

Vous pouvez "basculer" à une autre branche, supprimer maître, "switch" vers elle et puis de fusionner de nouveau:

# git checkout mybranch
# git branch -D master
# git checkout -b master trunk
... continue with merge...
# git merge --squash mybranch

... vous avez maintenant mybranch fusionnés en maître et prête à l' commit puis dcommit de trunk

Answer 3

Si vous n'avez pas fait de s'engager sur le master, cela signifie que l' git merge mybranch a été rapide-vers l'avant: master HEAD il suffit de déplacer à l' mybranch HEAD.

Cela pourrait expliquer pourquoi l' git svn dcommit poussé vos modifications à l' SVN mybranch.
Ça serait:

• d'abord mettre à jour le correspondant de la branche SVN avec la dernière Git mybranch s'engage à ne pas encore dcommitted,
• enregistrement de la fusion, du tronc, sur le SVN côté
• et puis il serait rebase maître sur le Git côté (rien à faire, déjà).

Je ne pense pas que le maître n'a pas changé sa référence, mais si vous avez un doute (et votre répertoire de travail est propre), vous pourriez, si le maître est sorti):

git reset --hard remotes/trunk

Answer 4

En général, vous ne devriez pas utiliser git merge avec git svn, parce que svn, même avec des branches, ne prend pas en charge le type de suivi de fusion que git n'. Lorsque vous avez besoin de fusionner une branche, j'ai eu le plus de succès (au moins avec les récentes svn) faire une plaine svn checkout/processus de fusion et ensuite à l'aide d' git svn rebase de mettre à jour mon git-svn repository. Cela préserve svn natif de suivi de fusion des métadonnées, qui (à ma connaissance) git-svn est complètement ignorant de.

Je ne suis pas totalement sûr de ce que l'état de votre dépôt svn est en -- je voudrais vérifier pour s'assurer de la fusion dcommit fait ce que vous vouliez sur le tronc. Même si elle l'a fait, Je parie que si vous regardez le contenu de l' refs/heads/master et refs/remotes/trunk des fichiers dans votre pension, vous verrez qu'ils sont différents pour le moment. Si c'est le cas, je voudrais (pas de modifications locales présent) faire un git-svn fetch suivie par un git branch -f master remotes/trunk; git reset --hard master pour resynchroniser la branche git avec git-svn de suivi de la branche. Si vous avez des modifications locales, vous devrez vous engager à faire quelque chose comme git rebase master^4 --onto remotes/trunk, où 4 est le nombre de commits que vous devez conserver. Alternativement, si elles sont toutes validées, les ranger avec git stash première.

A défaut, vous pouvez toujours obtenir tout dans le svn et essuyez simplement le repo et obtenir une nouvelle caisse.

Answer 5

Nous avons utilisé avec succès git merge --squash dans git-svn branche de développement. Le problème avec git-svn est que, même si votre local git-svn clone peut stocker les informations de fusion, une fois que vous dcommit pour le dépôt svn, il est perdu.

Donc, pour d'autres (git-)svn utilisateurs de la fusion s'engage ressemble juste à de la plaine s'engage. Le squash est bon pour la même chose que git merge --no-ff (eg. la production d'une fusion s'engager sur le master), mais il comprend aussi une liste des commits réalisés dans la direction de la fusion, qui serait autrement perdue lorsque dcommitting.