我们正在使用git-svn来管理SVN仓库的分支。我们面临以下问题:在分支中用户X进行了多次提交后,用户Y希望使用git-svn将分支中的更改合并到trunk。我们看到的问题是,所有单个合并操作的提交消息看起来好像是由用户Y创建的,而分支中的实际更改是由用户X进行的。
有没有办法向git-svn表明合并时,使用原始提交消息/作者进行给定的更改而不是进行合并的人?
答案 0 :(得分:13)
git-svn手册页建议您不要使用合并。 “”建议你运行git-svn fetch和rebase(不要拉或合并)“”。话虽如此,你可以做你喜欢的事: - )
这里有2个问题。首先,svn只存储 commiter ,而不是像git那样存储补丁的作者。所以当Y将合并提交到trunk时,svn只会记录她的名字,即使这些补丁是由X编写的。这是git的惊人的功能,非常简单但对开源项目至关重要的是归因于变化对作者来说可以避免法律问题。
其次,git似乎没有使用相对较新的svn合并功能。这可能是暂时的,因为git正在积极开发并且新功能一直在增加。但就目前而言,它并没有使用它们。
我刚刚尝试使用git 1.6.0.2并且与使用svn merge执行相同操作相比,它“丢失”了信息。在svn 1.5中,一个新功能被添加到日志记录和注释方法中,因此主干上的svn log -g会为合并输出这样的内容:
------------------------------------------------------------------------
r5 | Y | 2008-09-24 15:17:12 +0200 (Wed, 24 Sep 2008) | 1 line
Merged release-1.0 into trunk
------------------------------------------------------------------------
r4 | X | 2008-09-24 15:16:13 +0200 (Wed, 24 Sep 2008) | 1 line
Merged via: r5
Return 1
------------------------------------------------------------------------
r3 | X | 2008-09-24 15:15:48 +0200 (Wed, 24 Sep 2008) | 2 lines
Merged via: r5
Create a branch
这里,Y提交r5,它将分支上的X的变化合并到主干中。日志的格式并不是那么好,但它在svn blame -g上自成一体:
2 Y int main()
2 Y {
G 4 X return 1;
2 Y }
这里假设Y只提交到trunk,我们可以看到一行由X(在分支上)编辑并合并。
所以,如果你使用svn 1.5.2,你现在可能更好地与真正的svn客户端合并。虽然你会在git中丢失合并信息,但通常很聪明,不要抱怨。
更新:我刚刚尝试使用git 1.7.1来查看过渡期间是否有任何进展。坏消息是git中的合并仍然不会填充svn:mergeinfo值,因此git merge
后跟git svn dcommit
将不会设置svn:mergeinfo,如果Subversion存储库是规范的,您将丢失合并信息来源,它可能是。好消息是git svn clone
读取svn:mergeinfo属性以构建更好的合并历史记录,因此如果正确使用svn merge
(它需要合并完整的分支),那么git clone对git来说是正确的用户。
答案 1 :(得分:6)
您可以使用移植来教git关于未在相关提交对象中表示的合并。
echo "$merge_sha1 $parent1_sha1 $parent2_sha1" >> .git/info/grafts
查找此信息非常简单:在找到有问题的合并提交时,您已经知道$merge_sha1
和$parent1_sha1
。通常,这种提交的提交消息将包含第二个父提交的SVN修订号,您只需将其转换为相应的提交ID:
git svn find-rev r$revnum $branch
Presto,您拥有创建移植物所需的全部3条信息。
答案 2 :(得分:2)
尝试使用--add-author-from和--use-log-author选项git-svn。