合并 git 中没有真正共同祖先的复制存储库的更改

我有一个项目 DemoA，它是基于 git 存储库 Project1 构建的。

不幸的是，DemoA 一开始只是 Project1 文件的副本，然后才变成一个实际的长期项目。我现在想让 Project1 成为 DemoA 的子模块，但更重要的是，希望合并对 DemoA 中从 Project1 派生的代码所做的更改。

我在 DemoA 上进行了子树拆分，以创建分支 P1，其中对 DemoA 中的 Project1 代码库进行了所有更改。

我还设法在将 Project1 实例化为存储库之前添加对 DemoA 所做的更改。

Project1
A - B - C - D                     - E
Demo1/P1
    (untracked changes) F - G - H - I

where the files in E are identical to F

我想要的是：

Project 1
A - B - C - D - E - G - H - I

显然，E 和 F 的哈希值不同，因此当我将 Demo1/P1 作为远程添加到 Project1 并尝试合并时，它抱怨没有共同的祖先。

我努力了使用格式补丁 https://stackoverflow.com/questions/2217452/in-git-how-do-i-create-a-single-patch-for-the-last-2-revisions，但是 git am 已经抱怨了

错误：file.xyz：索引中已存在

我试图重新定位到不同的分支 https://stackoverflow.com/questions/973268/replay-the-last-n-git-commits-on-a-different-branch/973403#973403, doing:

git rebase -s recursive -X subtree=project1dir --onto (E-hash) (F-hash) emptybranch

但我显然不明白它实际上在做什么，因为它似乎实际上并没有do任何事物。

有没有一种干净的方法来做到这一点？我不介意这个过程需要一些手动操作，但我想保留历史。

这都是中等难度的（实际难度取决于环境和你对 Git 的熟悉程度）。

如果文件在E and F确实相同，做到这一点的（或）简单方法是放入移植物（用git replace或移植文件），以便 Git 假装G的父提交是提交E。也就是说，你有：

A--B--C--D--E   <-- master

F-------------G--H--I   <-- refs/remotes/rem/P1

and git diff master rem/P1~4根本不产生输出（master名称提交E, rem/P1~4名称提交F，以及两棵树E and F完全匹配）。

You wish，至少作为一个中间产品，你有这个：

A--B--C--D--E   <-- master
             \
F             G--H--I   <-- refs/remotes/rem/P1

也就是说，您希望 Git 假装（至少出于某些目的和一段时间）提交G已提交E作为其父级。

Using git replace模仿旧的可怕的黑客移植

Git 移植正是这样做的：它们告诉 Gitpretend某些提交的父级是其他一些提交。但这些已被弃用，取而代之的是更通用的git replace https://www.kernel.org/pub/software/scm/git/docs/git-replace.html。您可以使用git replace进行新的提交G'类似于（但至少取代了大多数 Git 命令）G，唯一的区别是G' has E作为其父级。

然后你可以使用git filter-branch重新复制存储库中的提交，以便此替换变得真实且永久，而不仅仅是副本。当然，您将获得新提交的新提交哈希值（G'可以保留它的哈希值，但你必须得到一个新的H' and I'). See Jakub Narębski 的回答 https://stackoverflow.com/a/3811028/1256452， 进而git 移植和替换有何不同？ （移植现在已经被废弃了吗？） https://stackoverflow.com/q/6800692/1256452，其中 VonC 链接到 Jakub 的答案。

（Git 移植仍然有效，你可以将提交的哈希值放在G and E into .git/info/grafts: echo $(git rev-parse rem/P1~3) $(git rev-parse master) > .git/info/grafts， 例如。但他们are这是一个可怕的黑客行为，如果你做了这种伎俩，最好是事后立即运行你的过滤器分支，正如 Jakub 指出的那样。）

Using git rebase

您还可以使用git rebase --onto，正如您所尝试的那样，但是您必须使用现有的（普通的，本地的）分支名称来启动此变基（我不确定在哪里emptybranch来自这里）指向提交I。我认为您可能缺少的步骤可能是制作这个常规的普通本地分支名称：

git checkout -b rewrite rem/P1

例如，假设名称rem/P1决心承诺I. Or git checkout -b rewrite <hash-of-I>，如果您面前有该哈希值以便于剪切/粘贴。那时你会得到这个：

A--B--C--D--E   <-- master

F-------------G--H--I   <-- HEAD -> rewrite, rem/P1

也就是说，您现在正在使用这个新的rewrite分支，指向提交I。现在你可以git rebase --onto master HEAD~3复制当前分支上最近的 3 个提交 -G, H, and I。副本将是G', H', and I'，与父母G' being E——承诺master点——以及H' being G'等等：

              G'-H'-I'   <-- HEAD -> rewrite
             /
A--B--C--D--E   <-- master

F-------------G--H--I   <-- rem/P1

现在您可以删除远程及其远程跟踪分支，因为您拥有所需的提交链。您还可以快进master指向提交I'任何时候，如果这是你想要的。