免责声明:我现在已经对此进行了测试,它似乎可以按预期工作(当然,假设我理解正确)。但是,仍然有很多地方可能出错。绝对只在项目存储库的单独工作副本上尝试此操作,并确保在将其推送到任何地方之前检查所有内容。在执行此操作之前保留状态的完整目录备份。
所以我假设你有两个独立的存储库。原始项目(Gephi):
A---B---C---D---E
^ HEAD of Gephi
还有您的项目,其第一个修订版看起来与原始项目的最后一个修订版相同:
E'---V---W---Y---...---Z
^ HEAD of your project
(可能有一些分支,但这并不重要。)
你想要的(如果我理解正确的话)是:
A---B---C---D---E---V---W---Y---...---Z
您可以尝试以下方法。同样,在您自己的独立工作树上执行此操作,并确保在将其推送到任何中央存储库之前一切都井井有条!
在您自己的工作树目录中,获取原始 Gephi 存储库的头和对象:
git fetch /path/to/original/gephi
如果您还没有克隆 Gephi 存储库,您不妨指定 github URL 而不是本地文件系统路径。
这将在您当前的工作树中导致以下情况:
A---B---C---D---E
^ FETCH_HEAD
E'---V---W---Y---...---Z
^ HEAD
我们并没有太大的改变。目前,这两个头和平共处,彼此完全独立,但您现在可以访问两个存储库中的对象并可以尝试将它们组合起来。
我们现在要丢弃 E'(它应该与 E 相同),而是将 E 作为项目第一次提交的父级,即 V。为此,您可以使用git filter-branch
:
git filter-branch -f --parent-filter 'test $GIT_COMMIT = <V> && echo "-p <E>" || cat'
分别用 V 和 E 的提交哈希替换<V>
和。<E>
要找出这些,您可以git log
检查项目的提交,并且由于我们已经获取了它们,git log FETCH_HEAD
因此可以检查 Gephi 的提交。
这将有效地将 V 直接连接到 E。
如果事实证明原始 Gephi 存储库的头部(即最新提交)不是您的项目所基于的,这甚至应该可以工作,这意味着 Gephi 中有新的提交,而您还没有(还没有?)已搞定。请确保,再次<E>
用您所做的更改所基于的提交的哈希代替,而不是用头部。
相反,请确保用您所做的第一个更改<V>
的哈希值替换。也许您的存储库不包含与 E 相同的 E',但第一次提交已经包含对原始版本的更改。那么这个第一个提交哈希将是你的,而不是它之后的那个。<V>
总结最后两段:如果您的情况如下所示,上述命令也应该有效,例如:
A---B---C---D---E---F---G---H---I
^ ^ FETCH_HEAD
point where your project branched off
V---W---Y---...---Z
^ ^ HEAD
first change based on E
只要确保使用在这种情况下有意义的提交哈希。