【问题标题】:Tracking master development in GIT with patches使用补丁跟踪 GIT 中的主开发
【发布时间】:2015-02-20 10:32:11
【问题描述】:

我的情况如下:

  1. 在 git 下维护了一个开源项目 (AT91B),定期发布。
  2. 在 3.7.0 版中,此项目由 ACME 克隆并进行了修改。
  3. AT91B 已更新并发布更多版本
  4. ACME 不会主动跟踪 AT91B。
  5. 现在 AT91B 是 3.7.1
  6. 我可以访问(我可以“git clone”)两个 git 存储库。

我需要的是一个 patch(或一组补丁,如果需要的话)应用到 AT91B-3.7.1 tarball 以集成 ACME 更改(由几个新文件和对现有文件的一些小调整)。

我知道这应该是相当标准的 git 东西(我不太了解 git,只是基本的东西;合并仍然不在我的视线范围内,但我想我必须学习)。问题是我需要使用 tarball(原始版本)+ 补丁(如果需要,是自制的)。

如何制作这样的补丁[set]?

更新

我尝试使用git format-patch -M -B -C -k --stdout refs/remotes/origin/at91bootstrap-3.x >my.patch,但这并不好,因为它为每个文件生成多个条目(显然每个提交一个),然后patch 的使用导致多次拒绝(IIRC 仅第一次成功)。

如何“压平”补丁?

【问题讨论】:

  • 如果上游项目和 ACME 的克隆都是用 git 管理的,你为什么还要为补丁和 tarball 烦恼呢?您是说“我需要使用 tarball ......”但这是因为您不了解合并而决定的限制吗?
  • @MagnusBäck:不,这个包实际上被插入到一个更大的构建系统(buildroot)中,它会获取压缩包,并可以选择修补它们; AFAIK 它没有提供 git 克隆,因此需要。
  • 您应该能够通过创建一个本地分支来扁平化补丁,在该分支中您将提交压缩为单个提交,然后从该分支创建补丁。

标签: git merge patch git-merge


【解决方案1】:

记录在案: 它比预期的要简单得多。 我真的不明白为什么挖掘信息如此困难(很多感谢@Rob Di Marco(请参阅:https://stackoverflow.com/a/616851/1714490)。

解决方案是使用“git diff”;就我而言:

git diff -M -B -C refs/remotes/origin/at91bootstrap-3.x >whatever.patch

当然,你必须处理任何冲突,但这是标准程序。

【讨论】:

    猜你喜欢
    • 2015-05-21
    • 2011-06-13
    • 1970-01-01
    • 2011-06-13
    • 2018-03-01
    • 2020-08-13
    • 1970-01-01
    • 2014-10-31
    • 2011-04-14
    相关资源
    最近更新 更多