如何愚弄git-svn来识别与svn合并？ [英] How to fool git-svn to recognize merges made with svn?
问题描述
我们有一个SVN设置，具有稳定的主干和不稳定的开发分支。开发工作（大部分）在分支上完成，然后在部署之前合并到主干。
我使用git-svn作为我的SVN客户端。从不稳定到中继的合并过程如下：
git svn fetch
git co -b trunk svn / trunk
git merge --no-ff svn / unstable
git svn dcommit
svn / * 是远程SVN分支。
这当然要求在完成之前没有人向干线提交任何东西，但这在实践中并不是问题。
这个过程的好处是，git现在会在本地资源库中记录合并提交的父项。这对我的同事没有好处，但是当 I 进行合并时，它确实允许git计算共同的祖先。这是非常理想的。
这里是蹭。当其他人进行合并时，git不知道它。这里是一个例子：
o -...- A --- o --- C --- unstable
/
X --...-- B --- o --- o --- stable
不稳定的分支是在X点创建的。在A点，我们决定合并来自不稳定分支的变化到B点的稳定分支。共同的祖先正确地为X.
由于合并未记录在git历史记录中，因此C处的以下合并再次假定X是共同祖先。我希望它是A，如下图所示：
o -...- A --- o-- -C ---不稳定的
/ \
X ---...--- B --- o --- o ---稳定的
并不是绝对有必要得到一张看起来像图片那样完美的图。任何能够将A识别为共同祖先的图都可以。
我有一些选择，例如正确使用git-filter-branch或一个永远不会支持SVN的虚假提交。然而，我的尝试都没有足够的工作到目前为止。
我很感激你可以提出任何想法。程序不一定是自动的。合并是非常罕见的，我可以忍受手工操作所带来的痛苦。 解决方案
使用Grafts文件，它允许您在不实际操作历史的情况下覆盖提交的父项。
这意味着在SVN存储库中看到合并后，您只需在合并的SHA-1中添加一行到.git / info / grafts提交（M）及其父母（A，B）。
o -...- A --- o-- -D ---不稳定
/
X ----- B --- M --- o --- o ---稳定
A = 31423cd8a838f984547a908777308d846043cbda
B = d99cfccb1f859a8f1dbfac95eec75227fe518b23
M = 13319a54d3e3d61b501e7cc6474c46f37784aaa3
为了创建AM ，你可以将M的父母指定为B和A.移植文件的格式非常简单：
commit newparent1 ... newparentN
这意味着您将以下（较长）行添加到移植文件中：
13319a54d3e3d61b501e7cc6474c46f37784aaa3 d99cfccb1f859a8f1dbfac95eec75227fe518b23 31423cd8a838f984547a908777308d846043cbda
< Git会n ow假装实际发生了这种合并。作为缺点，这不会通过git push / fetch / clone传播，但这不应该是个人开发的主要问题。
We have an SVN setup with stable trunk and unstable development branch. Dev work is (mostly) done on the branch and then merged to trunk before deployment.
I use git-svn as my SVN client. My merge process from unstable to trunk is as follows:
git svn fetch
git co -b trunk svn/trunk
git merge --no-ff svn/unstable
git svn dcommit
svn/* are the remote SVN branches.
This of course requires that no one commits anything to the trunk before I am done, but this is not a problem in practice.
The benefits of this process is that git now records the parents of the merge commit in my local repository. This does not benefit my coworkers, but it does allow git to compute the common ancestor when I do the merge. This is very desirable.
And here is the rub. When someone else makes a merge, git doesn't know about it. Here is an example:
o-...-A---o---C--- unstable
/
X--...--B---o---o--- stable
The unstable branch was created at point X. At point A we decide to merge changes from the unstable branch into the stable branch at point B. The common ancestor is correctly X.
Because the merge is not recorded in the git history, the following merge at C again assumes X is the common ancestor. I would like it be A, as in the following graph:
o-...-A---o---C--- unstable
/ \
X---...---B---o---o--- stable
It is not absolutely necessary to get a graph that looks exacly like the one pictured. Any graph, which would recognize A as the common ancestor is fine by me.
I have some options in mind, such as a proper use of git-filter-branch or a "fake" commit which is never dcommited to SVN. However none of my attempts have worked sufficiently so far.
I am grateful for any ideas you can present. The procedure does not have to be automatic. The merges are pretty rare and I can live with the pain of doing it "by hand".
An additional alternative would be to use the Grafts file, which allows you to override the parents of a commit without actually manipulating history.
This means that after you see a merge in the SVN repository, you just need to add a line to .git/info/grafts with the SHA-1s of the merge commit (M) and its parents (A,B).
o-...-A---o---D--- unstable
/
X-----B---M---o---o--- stable
A = 31423cd8a838f984547a908777308d846043cbda
B = d99cfccb1f859a8f1dbfac95eec75227fe518b23
M = 13319a54d3e3d61b501e7cc6474c46f37784aaa3
In order to create the link from A-M, you would specify M's parents as B and A. The format of the grafts file is fairly straightforward:
commit newparent1 ... newparentN
This means you add the following (rather long) line to your grafts file:
13319a54d3e3d61b501e7cc6474c46f37784aaa3 d99cfccb1f859a8f1dbfac95eec75227fe518b23 31423cd8a838f984547a908777308d846043cbda
Git will now pretend that this merge actually occurred. As a downside, this doesn't get propagated via git push/fetch/clone, but this shouldn't be a major issue for personal development.
这篇关于如何愚弄git-svn来识别与svn合并？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
