2010-05-11 16 views
2

J'utilise git-svn pour travailler avec une base de code et j'ai besoin de fusionner les changements dans le tronc à mon branche.Fusionner dans git: via git-svn, dit déjà mis à jour, mais git-diff dit qu'il y a des différences

J'ai les deux branches récupérées dans git, et quand je lance git diff trunk alors que dans ma branche, je peux voir tous les changements.

Lorsque je lance git merge/trunk, cependant, je reçois un message "Déjà à jour".

Ce n'est clairement pas à jour. Qu'est-ce que je fais mal?

+0

Avez-vous vérifié à quoi il ressemble dans par exemple Gitk? – Makis

Répondre

1

« déjà à jour » peut signifier:

    tronc
  • est un parent of master (tous les changements de tronc ont déjà été fusionnées à maîtriser)
  • ou que vous travaillez sur un detached head (qui peut se produire si vous extrayez directement une référence de validation SHA1 ou une balise).

Note: être au courant des git svn caveats

suivi de fusion dans Subversion fait défaut et le développement fait ramifié avec Subversion peut être lourd en conséquence.
Alors que git svn peut suivre l'historique des copies (y compris les branches et les balises) pour les référentiels adoptant une mise en page standard, il ne peut pas encore représenter l'historique de fusion passé en amont vers les utilisateurs SVN.
Par conséquent, il est conseillé aux utilisateurs de garder l'histoire aussi linéaire que possible git l'intérieur pour faciliter la compatibilité avec SVN

Par souci de simplicité et interopérer avec un système moins capable (SVN), il est recommandé que tous les git svn utilisateurs clone , fetch et dcommit directement à partir du serveur SVN, et d'éviter toutes les opérations git clone/pull/merge/push entre les dépôts git et branches.
La méthode recommandée pour l'échange de code entre les branches git et les utilisateurs est git format-patch et git am, ou simplement «d'effectuer une connexion au référentiel SVN».

+0

Aha ... donc j'utilise trop de fonctionnalités git que de tirer de svn me le permet vraiment. Bon à savoir, merci! –

2

Rien à voir avec un exemple. Voici comment entrer dans cette situation:

(à partir dans un répertoire vide):

 
> git init 
> echo "hello" > a.txt 
> git add -A 
> git commit -m "Created a on master" 
> git branch test 
> git checkout test 

A ce stade a.txt sont identiques sur les branches de maître et de test

 
> echo "goodbye" > a.txt 
> git add -u 
> git commit -m "Changed a on test" 

maintenant (évidemment) il y aura des différences:

 
> git diff --name-status master 

M  a.txt 

encore git n'a rien à fusionner:

 
> git merge master 
Already up-to-date. 

C'est parce que les changements sont faits ici sur le test, pas sur le maître.Si vous passez à tester, diff fera rapport de même, mais la fusion va maintenant fusionner les changements de l'essai à maîtriser:

 
> git checkout master 
> git diff --name-status test 

M  a.txt 
> git merge test 
Updating 088cd9d..3d8c8e2 
Fast-forward 
a.txt | 2 +- 
1 files changed, 1 insertions(+), 1 deletions(-) 

fusion Git est directionnelle, la fusion de la branche A à B est pas la même que la fusion de B à A.