git插入子目录的历史更改

时间:2012-02-29 19:34:05

标签: git merge github

我明白这可能听起来像个奇怪的问题。

我在github https://github.com/milovanderlinden/NLExtract

上有一个回购

它有一个子目录“bag”,源自:https://github.com/MinIenM/BAG-Extract

在创建NLExtract期间,我们意外地忽略了在保留历史记录的同时正确合并BAG-Extract。

为了维护原作者的学分,我想从BAG-Extract到NLExtract / bag获取完整的提交历史。

这可能吗?关于如何进行“历史注入”的任何提示?

1 个答案:

答案 0 :(得分:2)

我想我可以帮助你,因为我之前需要做类似的事情。

缺点是我的解决方案需要一些历史重写。如果你有很多合作者,这将是痛苦的,因为每个人的历史都会发生变化。我知道并没有真正解决这个问题,因为即使是在当前root之前添加父提交这样简单的事情也会改变commit msg或我们的旧root,这会更改其SHA,这会影响其子节点的父字段,它改变了SHA,依此类推等等。

从github上的存储库看,看起来你只有几个贡献者,所以这不是很多毛。

我还假设https://github.com/MinIenM/BAG-Extract的行李存储库自你读入以来没有进展,从读取提交的日期和我认为的BAG-Extract提交就是这种情况。

因为听起来你的目标只是给予信任,所以可能适合你的子树合并。

我们基本上会做以下事情:

  1. 将BAG-Extract作为新分支读入。它将没有共同的历史。
  2. 确定您带入bag子目录的历史记录中的位置。我们称之为“bagin”
  3. 添加一个新的合并提交,它将具有最后一个BAG-Extract提交和来自(2)的提交作为父项。它将是一个子树合并,所以我的想法是两个父母的不同之处仅在于一个以子树为前缀(例如bag /)
  4. 将所有帖子“bagin”历史记录重新整合到此合并对象上。
  5. 这是一些代码。为了安全起见,我将事物克隆到一个新的存储库,如果事情没有按计划进行,你可以扔掉它

    git clone git@github.com:milovanderline/NLExtract
    git log -- bag #Identify the first commit where "bag" enters. It starts with 78575
    git checkout 78575 -b bagin
    git remote add bag git@github.com:MinIenM/BAG-Extract
    git fetch bag
    git checkout bagin -b baginmerge
    git merge bag/master -s subtree #Create the new merge object. baginmerge now points to the merge object. bagin, which hasn't moved, now has two children, one is the merge object, the other is your old history.
    git rebase --onto baginmerge bagin master -p #Calculate the diffs from bagin to master, and replay them onto baginmerge. The -p flag tells rebase to preserve merges.
    

    事实上,我已经分叉了您的存储库并完成了上述步骤。在https://github.com/dankessler/NLExtract的我的存储库中,您将找到一个名为rebased_master的新分支。随便把它拉进去。不幸的是,通过查看你的网络图,人们已经从你的回购中分离出来,这可能会搞砸他们,但他们应该能够从以后的任何更新中重新定位或挑选你的提交应该是相同的,只是他们的SHA已经改变了。

    如果您查看http://help.github.com/subtree-merge/子树合并策略主要类似,那么这应该可以让您根据需要从BAG-Extract中获取未来的开发。

    我可以想到另一个策略,看起来好像开发包最初是作为你的存储库的子树(但是有适当的作者ID),但那可能不是你的正在寻找。这样做的好处是像git blame这样的实用程序可能会更好用,但它要复杂得多,需要git filter-branch我应该尽可能避免使用{{1}}。但是,如果你想走这条路,请告诉我,我会更详细地解释。

    祝你好运和欢呼!