将git叉应用于不同的存储库？
我正在工作的项目，repo被复制（未分叉），并用作其他项目的基础，repo b。这些现在是两个不同的存储库，具有完全不同的历史，没有共同的提交。 repo b现在是800个投入，repo a是60个提交
repo A
- CA1 - CA2 - ... - CA60
repo B
- CB1 - CB2 - ... - CB800
where CA is a commit on repo A, and CB is a commit on repo B.
Note that there is no common commit, since the files were copied, instead of forking
the repo.
。 repo a的叉子，将所有更改从repo a中应用，然后应用repo b的更改。结果应该看起来像这样：
fork repo A
- CA1 - CA2 - ... - CA60 - CB1 - CB2 - ... - CB800
初始想法
最初，我是要创建800个提交的补丁repo b，然后将它们应用于forked repo a 。但是，考虑到源文件不再相同，并且每个补丁文件都需要手动更改，这是一项繁琐的任务，当然也不是错误的。
然后，我想到了另一种方法并将其从repo a应用于repo b，但虽然这并不那么乏味，但不会有通信在repo a中的原始提交与应用于repo b的那些提交之间，因为现在repo b具有其自己的更改。
当前的想法
所以现在我正在考虑创建repo a的叉进入新存储库，从而重新创建存储库。这将导致：
fork repo A
- CA60 - CN1 - CN2 - ... -CNN
where CN is a new commit to replicate the functionalities of repo B
这只是可悲的...
问题
是否有更好的方法来配置repo b作为最新的repo a和然后应用repo b的更改？请记住，他们共享没有共同的订单。
The project I'm working, repo A was copied (not forked) and used as a base in a different project, repo B. These are now two distinct repositories, with completely distinct histories and no common commit. repo B is now 800 commits in and repo A is 60 commits in.
repo A
- CA1 - CA2 - ... - CA60
repo B
- CB1 - CB2 - ... - CB800
where CA is a commit on repo A, and CB is a commit on repo B.
Note that there is no common commit, since the files were copied, instead of forking
the repo.
Now that the problem was discovered, we want to configure repo B as a fork of repo A, apply all changes from repo A and then apply the changes of repo B. The result should look like this:
fork repo A
- CA1 - CA2 - ... - CA60 - CB1 - CB2 - ... - CB800
Initial thoughts
Initially, I though of creating patches of the 800 commits of repo B and apply them on a forked repo A. However, considering that the source files are no longer the same, and that each patch file would need manual changes, this is a tedious task and certainly not error proof.
Then I thought of trying the other way around and applying the commits from repo A to repo B, but while this isn't so tedious, there wouldn't be a correspondence between the original commits in repo A and those applied to repo B because now repo B has its own changes.
Current thoughts
So now I'm thinking of creating a fork of repo A and then slowly and painfully integrate the changed files (not the commits), of repo B into the new repository and thus recreate the repository. This would result in:
fork repo A
- CA60 - CN1 - CN2 - ... -CNN
where CN is a new commit to replicate the functionalities of repo B
It's just sad ...
Question
Is there a better way for configuring repo B as fork for the latest repo A and then applying the changes of repo B? Keep in mind they share no common commit.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论