왜“우리”와“자신”의 의미가 git-svn으로 바뀌 었습니까?

왜“우리”와“자신”의 의미가 git-svn으로 바뀌 었습니까?

---

나는 git-svn을 사용하고를 수행 한 후 병합 충돌을 수정해야 할 때 및 옵션 git svn rebase의 의미 가 반전 된다는 것을 알았습니다 . 즉, 충돌이 있고 SVN 서버에서 가져온 버전을 유지하고 로컬에서 변경 한 사항을 버리고 싶다면를 사용해야 합니다 .--ours--theirsgit checkoutourstheirs

왜 그런 겁니까?

예:

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"

---

그것은 rebase가하는 일과 일치하는 것 같습니다.

• git svn rebase 현재 HEAD의 SVN 상위에서 개정을 가져오고 이에 대해 현재 (SVN에 커밋되지 않은) 작업을 리베이스합니다.

• git rebase언급하지 않습니다.
  리베이스 병합은 브랜치 상단의 작업 브랜치에서 각 커밋을 재생하여 작동합니다 <upstream>.
  이 때문에 병합 충돌이 발생하는 경우 :

  • 우리의 것으로보고 된 측면은로 시작하는 지금까지 리베이스 된 시리즈입니다<upstream> .
  • 그리고 그들의 것은 작업 지점 입니다.
    즉, 측면이 서로 바뀝니다 .

git rebase는 <upstream>분기 상단의 작업 분기에서 각 커밋을 재생합니다 .

두 정의를 모두 조정하는 경우 :

• SVN에서 오는 커밋은 로컬 Git 커밋이 재생되는 맨 위에있는 커밋입니다. 그것들은 "지금까지 리베이스 된 시리즈"의 일부이며 "우리"로 참조됩니다 (귀하의 경우 콘텐츠가 있는 test.txt파일 bar).
• the working branch (containing Git commits unknown to SVN, in your case, the test.txt file with baz content) is "their", and each of those local Git commits are being replayed.

In other words, SVN or not:

• the "<upstream>" branch (on top of which anything is replayed, and which is part of the so far rebased commits") is "ours".
• what is being replayed (the working branch) is "theirs".

---

Good mnemonic tip by CommaToast:

whatever HEAD's pointing to is "ours"

(and the first thing a git rebase upstream does it to checkout the upstream branch on top of which you want to rebase: HEAD refers to upstream -- ours now.)

---

The confusion is likely coming from the role of the working branch in a classic git merge.
When you are merging:

• the "working branch" is the one containing what is "so far merged", and is considered as "our",
• while the other commit represent what is being -- not replayed but -- merge on top of the working branch, and considered as "their".

As the git rebase man page mentions, a merge during a rebase means the side are swapped.

---

Another way to say the same thing is to consider that:

• what we have on the checked out branch is 'ours',
• what we had (and is being merged or replayed) is 'theirs'.

---

On a merge:

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

, we don't change the current branch 'B', so what we have is still what we were working on (and we merge from another branch)

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

---

But on a rebase, we switch side because the first thing a rebase does is to checkout the upstream branch! (to replay the current commits on top of it)

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

A git rebase upstream will first change HEAD of B to the upstream branch HEAD (hence the switch of 'ours' and 'theirs' compared to the previous "current" working branch.)

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

, and then the rebase will replay 'their' commits on the new 'our' B branch:

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

---

The only extra step with git svn rebase is that a svn "fetch" is performed first on the Git remote branch representing SVN commits.
You have initially:

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

, you first update the SVN tracking branch with new commits coming from SVN

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

, then you switch the current branch to the SVN side (which becomes "ours")

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")

, before replaying the commits you were working on (but which are now "theirs" during that 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

참고URL : https://stackoverflow.com/questions/2959443/why-is-the-meaning-of-ours-and-theirs-reversed-with-git-svn