0

基本上,当我想在同一个文件中提交由git add --patch <file>操作导致的两个单独的更改时, git svn rebase 稍后会在用于第二次更改时在提交第二次更改时引发 1-2 冲突git add

所以我基本上是这样做的(我在 master 分支上并且已经获取了 svn 存储库):

git checkout -b feature
... make two unrelated changes to file test.txt...
git add --patch test.txt
... add first change but ignore second one
git commit -m "change1"
git stash
git checkout master
git merge feature
git svn rebase
git svn dcommit
git checkout feature
git stash apply

现在这里有两种方法可以做到,第一种可行:

git add --patch test.txt
... select everything (which is the second change in this case)
git commit -m "change 2"
git checkout master
git merge feature
git svn rebase
git svn dcommit

这是一个不起作用的:

git add test.txt #notice there's no --patch
git commit -m "change 2"
git checkout master
git merge feature
git svn rebase #yields a conflict

那么为什么在git add --patch用于第二次更改时,我可以毫无问题地提交到svn存储库,但是当仅git add用于第二次更改时,会导致冲突?我对 git 很陌生,所以这可能是一个愚蠢的问题,但在我看来,两个命令集应该完全相同。

4

1 回答 1

1

你为什么要为你的 2 个提交创建一个分支然后合并回来?我想这可能会带来问题,因为 git 中的合并与它们在 svn 中的工作方式不同。

这应该有效(“应该”,但我很确定它确实有效):

# on master, no need to create a branch
$ git add -p file
$ git commit -m "first set of changes"
$ git add file
$ git commit -m "the remaining changes"
# apply your commit on top of eventually new changes upstream
$ git svn rebase
# commit your 2 commits to svn
$ git svn dcommit

在 svn 中的分支只是目录的副本(通常是主干目录),合并提交与普通提交没有区别(除了svn:mergeinfo从 svn 1.6 开始的新属性)

git 中的提交是不同的,每个提交都存储一个指向其父提交的链接。svn 不需要这个,因为它可以简单地使用 REV-1。git 中的合并提交因此有多个父级(合并分支和合并分支)

我不知道如果您将 git 提交到 svn 会发生什么,但它可能只会提交合并提交本身,没有历史记录(消息类似于“将分支 'bla' 合并为 'master')。

当您运行时,svn commit只会将您的新更改发送到服务器以节省带宽。现在,git 中的合并工作不同了,与以前版本的差异可能不会像您期望的那样,这就是git svn dcommit失败的原因。

它甚至在 git svn 文档中这样说:不要使用 git 合并分支并将它们提交到 svn,它很可能会弄乱你的历史

不建议在您计划从中进行 dcommit 的分支上运行 git merge 或 git pull 。Subversion 不代表任何合理或有用的合并;因此使用 Subversion 的用户看不到您所做的任何合并。此外,如果您从作为 SVN 分支镜像的 git 分支合并或拉取,dcommit 可能会提交到错误的分支。 git svn 文档

于 2010-09-05T11:44:22.897 回答