为什么“我们的”和“他们的”的意思与 git-svn 相反

我使用 git-svn，并注意到当我在执行 git svn rebase之后需要修复合并冲突时，--ours和 --theirs选项对于例如 git checkout的意义是相反的。也就是说，如果存在冲突，我想保留来自 SVN 服务器的版本，并放弃在本地进行的更改，我必须使用 ours，而我希望它是 theirs。

为什么？

例如:

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"
39188 次浏览
小开
最佳答案

That seems consistent with what a rebase does.

  • git svn rebase will fetches revisions from the SVN parent of the current HEAD and rebases the current (uncommitted to SVN) work against it.

  • git rebase does mention:
    Note that a rebase merge works by replaying each commit from the working branch on top of the <upstream> branch.
    Because of this, when a merge conflict happens:

    • the side reported as ours is the so-far rebased series, starting with <upstream>,
    • and theirs is the working branch.
      In other words, the sides are swapped.

git rebase replays each commit from the working branch on top of the <upstream> branch.

If you reconcile both definitions:

  • the commits coming from SVN are the ones on top of which local Git commits are replayed. They are part of the "so-far rebased series", and are referenced as "our" (in your case, the test.txt file with bar content)
  • 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

提交答案