Pourquoi est-ce que le sens de « nôtre » et « le leur » inversé avec git-svn

Question

J'utilise git-svn et j'ai remarqué que quand j'ai à résoudre un conflit de fusion après l'exécution d'un git svn rebase, le sens de l' --ours et --theirs options, par exemple git checkout est inversé. C'est, si il y a un conflit et je veux garder la version qui est venu à partir du serveur SVN et jeter les changements que j'ai faits localement, je dois utiliser ours, lorsque je m'attends à ce qu'il soit theirs.

Pourquoi est-ce?

Exemple:

mkdir test
cd test
svnadmin create svnrepo
svn co file://$PWD/svnrepo svnwc
cd svnwc
echo foo > test.txt
svn add test.txt
svn ci -m 'svn commit 1'
cd ..
git svn clone file://$PWD/svnrepo gitwc
cd svnwc
echo bar > test.txt 
svn ci -m 'svn commit 2'
cd ..
cd gitwc
echo baz > test.txt 
git commit -a -m 'git commit 1'
git svn rebase

git checkout --ours test.txt
cat test.txt 
# shows "bar" but I expect "baz"

git checkout --theirs test.txt
cat test.txt 
# shows "baz" but I expect "bar"

Answer 1

Qui semble cohérent avec ce qu'est un rebase.

• git svn rebase sera récupère les révisions de la SVN parent de l'actuel CHEF et rebases le courant (non validées à SVN).

• git rebase ne mentionne:
  Notez qu'un rebase fusion fonctionne en relisant chaque commit de la branche sur le dessus de l' <upstream> de la branche.
  De ce fait, lorsqu'un conflit de fusion qui se passe:

  • le côté rapporté que le nôtre est loin relocalisée série, en commençant par <upstream>,
  • et c'est le travail de la branche.
    En d'autres termes, les côtés sont inversés.

git rebase rejoue à chaque commit de la branche sur le dessus de l' <upstream> de la branche.

Si vous concilier les deux définitions:

• l'engage à venir à partir de SVN qui sont sur le dessus de ce qui Git local s'engage sont relus. Ils font partie de la "mesure relocalisée série", et sont référencés comme "notre" (dans votre cas, l' test.txt fichier bar de contenu)
• le travail de la branche (contenant Git s'engage inconnu SVN, dans votre cas, l' test.txt fichier baz de contenu) est "leur", et chacun de ceux qui Git local s'engage sont relus.

En d'autres termes, SVN ou pas:

• le "<upstream>" de la branche (sur le haut de où tout est relu, et qui fait partie de la mesure relocalisée s'engage") est "nôtre".
• ce qui est nouveau (la branche) est "la leur".

---

Bonne astuce mnémotechnique par CommaToast:

quelle que soit la TÊTE de pointage est "nôtre"

(et la première chose que l' git rebase upstream t-il à la caisse de la upstream de la branche sur laquelle vous souhaitez rebase: la TÊTE se réfère upstream -- ours maintenant).

---

La confusion est probablement en provenance du rôle de la branche dans un classique git merge.
Lorsque vous fusionnez:

• la "branche" est l'un contenant qu'est-ce que "jusqu'à présent fusionné", et est considéré comme "notre",
• tandis que les autres commettent représenter ce qu'est l'être-pas relu, mais -- merge sur le dessus de la branche, et considéré comme "leur".

Comme l' git rebase page de manuel mentionne, une fusion lors d'un rebase signifie que le côté sont inversés.

---

Une autre façon de dire la même chose, c'est de considérer que:

• ce que nous avons sur l'extrait de la branche est un 'nôtre',
• ce que nous avons eu (et est fusionnée ou relu) est 'leur'.

---

Sur une fusion:

x--x--x--x--x(*) <- current branch B ('*'=HEAD)
    \
     \
      \--y--y--y <- other branch to merge

nous n'avons pas changer la direction de 'B', donc ce que nous avons est toujours ce que nous étions (et nous fusion à partir d'une autre branche)

x--x--x--x--x---------o(*)  MERGE, still on branch B
    \       ^        /
     \     ours     /
      \            /
       --y--y--y--/  
               ^
              their

---

Mais sur un rebase, nous changeons de côté parce que la première chose qu'un rebase n'est à la caisse de l'amont de la branche! (relire le courant s'engage sur le dessus de celui-ci)

x--x--x--x--x(*) <- current branch B
    \
     \
      \--y--y--y <- upstream branch

Un git rebase upstream sera premier changement HEAD de B à l'amont de la branche HEAD (d'où le commutateur de "les nôtres" et "les leurs", par rapport à la précédente "actuel" de travail de la branche.)

x--x--x--x--x <- former "current" branch, new "theirs"
    \
     \
      \--y--y--y(*) <- upstream branch with B reset on it,  
                       new "ours", to replay x's on it

et puis cela va de relecture de "leurs" s'engage sur la nouvelle 'notre' B branche:

x--x..x..x..x <- old "theirs" commits, now "ghosts", available through reflogs
    \
     \
      \--y--y--y--x'--x'--x'(*) <-  branch B with HEAD updated ("ours")
               ^
               |
        upstream branch

---

La seule étape supplémentaire avec git svn rebase est un svn "fetch" est d'abord effectué sur le Git remote représentant de la branche SVN s'engage.
Vous devez d'abord:

x--x--x--x--x(*) <- current branch B, "ours" for now.
    \                                   
     \
      \--y--y--y <- SVN tracking branch, "theirs for now"

, vous devez d'abord mettre à jour le SVN de suivi de la direction, avec la nouvelle s'engage à venir à partir de SVN

x--x--x--x--x(*) <- current branch B, still "ours", not for long
    \                                   
     \
      \--y--y--y--y'--y' <- SVN tracking branch updated

, puis vous passez la branche courante dans le SVN côté (qui devient "les nôtres")

x--x--x--x--x <- for "B", now "their" during the rebase
    \                                   
     \
      \--y--y--y--y'--y'(*) <- SVN tracking branch updated, and branch B: 
                               now "ours" (this is "what we now have")

avant de relire les commits que vous travailliez (mais qui sont maintenant "leurs" pendant que rebase)

x--x..x..x..x <- old "theirs" commits, now "ghosts", available through reflogs
    \
     \
      \--y--y--y--y'--y'--x'--x'--x'(*) <-  branch B with HEAD updated ("ours")
                      ^
                      |
        upstream SVN tracking branch