问题标签 [format-patch]

有什么方法可以让使用 git format-patch 创建的补丁与 svn 兼容，以便我可以将其提交到 svn repo？

我正在 github 上处理一个 svn 存储库，并希望将我的更改提交回主存储库。我需要创建一个补丁来执行此操作，但是无法应用该补丁，因为 git 格式的补丁与 svn 不同。有什么我还没有发现的秘密吗？

更新：虽然目前不存在执行此操作的脚本或本机 git 方法，但我确实设法从今年早些时候找到了一篇关于如何手动完成此操作的帖子。我已按照说明操作并成功让我的 git 补丁与 svn 一起使用。

如果有人可以尝试编写脚本来完成此任务并为 git 项目做出贡献，我将不胜感激。

http://kerneltrap.org/mailarchive/git/2008/1/15/570308/thread#mid-570308

我有两个不同的分支，以至于变基似乎不起作用——或者我不知道该怎么做。

我有一个“公共”分支，其中删除了一堆文件（使用过滤器分支）。尽管大多数提交在增量方面匹配，但提交 ID 都是不同的。我已经尝试了很多方法来将更改从我的开发分支拉到我的公共分支......我发现很难相信它可以做我想做的事——但我怀疑我只是不知道如何去做做。无论如何，这工作正常，但似乎是错误的。

欢迎任何提示或建议，其中可能包括不过滤分支出您不希望在公共分支上的文件（但是，您如何摆脱它们？）。

我的树或多或少看起来像这样：

t ≅ a, u ≅ c, v ≅ d, w ≅ e, x ≅ g。i,j,k 是我想迁移的新补丁。

我有一个带有“基本站点”的基本存储库，我克隆它以创建我的客户站点，所以我工作、提交、推送到客户端分支，然后我意识到在我的提交中间有一个或多个必须合并到基础存储库。这就是我所做的：

git 格式补丁 -1 SHA

然后我转到“基础站点”存储库并执行以下操作：

git am -3 补丁文件

没关系。问题是当我想将更改从“基础站点”拉到客户端存储库时，提交被重复。

有没有办法避免这种情况？也许不同的工作流程？

编辑：

事实上我仍然有问题，我的解释不是很清楚。让我再尝试一次：

我有一个包含“docs”、“layout”、“pub”和“sql”文件夹的基本存储库，“docs”和“layout”文件夹中只有一个空白的“index.html”。在“pub”文件夹中，我安装了 Joomla。

当我有一个新客户时，我创建他的目录并初始化一个存储库，然后我添加一个指向基本裸存储库的远程“base”，获取它，checkout base/master，然后执行“checkout -b master”来创建master从基地的主分支分支。然后我在我的本地服务器中创建一个“克隆--bare”并在本地工作站中克隆它。我们在需要时保存文档，设计师制作布局，然后将所有内容提交并推送到客户的裸仓库。我们总是在推送之前做一个“rebase origin/master”，以确保本地 repo 是最新的。

因此，当布局完成并推送后，我将其拉出并开始制作 Joomla 模板。所以我做了很多提交，然后我意识到我必须对我们的 Joomla 组件进行更改以使其正常工作。好的，我更改了一个组件，提交并继续制作模板，提交，...

现在我想将所有组件的提交带到“基本仓库”，因为我希望我的所有客户都有相同的更改。当我尝试@jleedev 解决方案时，我所有客户的提交都到了顶部，重写了已经在客户的裸仓库中的 SHA。

有任何想法吗？

谢谢！

我使用三个提交创建了一个补丁

这会创建三个补丁文件，我从我的笔记本上邮寄并在我的台式计算机上阅读邮件（两者都是 Windows 机器）。

当我现在做

补丁适用，但我没有为提交获得相同的 SHA1 ID。在修补的文件中搜索了一下，我发现我的台式计算机上修改后的行以 . 结尾LF，而笔记本（我创建补丁的地方）上的修改行以CR LF.

git am所以，我的第一个想法是不打电话--ignore-space-change，但这给了我一个错误（补丁不适用）。

我怎么知道git format-patch或git am关于如何处理行尾（msysgit 1.7.4）？

在我可以应用补丁之前，我真的必须使用 VIM 并将文件格式从 更改为UNIX吗？DOS

编辑：甚至用 VIM 修改补丁文件都没有帮助：我想，set ff=dosa:%s/^M//g会有所帮助，但它没有！

在我看来，应用补丁应该会产生完全相同的内容和相同的提交哈希，就像我从创建补丁的另一个仓库中提取的一样。我想错了吗？

我一直在使用 git-format-patch 和 git-am 将更改从一个存储库应用到另一个存储库。文件结构是相同的，但是我应用的存储库中有一些更改导致大多数补丁失败了一些大块。但是大多数补丁程序都在行号中应用了一些模糊性。

据我所知，git-am apply这是一个非常严格的解释，所以完全拒绝所有这些补丁。

所以我的工作流程变成了

如果我不必运行命令行补丁并且可以将其作为 am 命令的一部分发生，那就太好了。

如果有任何冲突，使用该--reject标志运行似乎会创建一个包含文件中所有块的 .rej 文件，这不是我想要的。

使用--3way标志运行失败

我认为这是因为基于此的更改集不在我要合并的存储库中。

有没有办法git-am apply像原始补丁命令一样使用模糊匹配制作补丁，并且只创建包含失败的大块的 .rej 文件？

假设有两个分支，master和slave，它们编辑同一个文件和同一行。最初，文件的内容是

然后在分支中将slave其编辑为

现在 branch 的用户slave格式化 patch( git format-patch master) 并将其发送给 branch 的用户master。同时，在分支master中，同一个文件被编辑，变成

补丁无法应用，并master要求slave合并并制作新补丁。当master被合并slave并解决冲突时，是时候重新格式化补丁了。提交图如下所示：

最新的提交（合并）slave如下所示：

但是，如果我们现在运行git format-patch master，我们仍然会得到与以前完全相同的补丁，它没有考虑合并和冲突解决：

如何格式化适用于最新母版的补丁？我想在没有rebase.

更新：git format rev1..rev2， whererev1和rev2are 分别是master和custom分支的负责人，不包括与冲突解决相关的更改。git-diff格式化一个有效的补丁，但忽略提交消息。

我有一系列想要发送到开源项目的补丁，但我无法弄清楚如何正确格式化电子邮件。我尝试运行 git format-patch 命令，然后将它们全部附加到来自 Thunderbird 的电子邮件中，但它们都被拒绝了，因为每个补丁本身应该是一封单独的电子邮件。我想避免使用 git email 命令，因为我在同一棵树中拥有私有代码和一些需要发送的代码，这意味着我需要能够在发送之前手动查看每封电子邮件。

我想继续使用 Thunderbird，但它似乎有问题，因为它会换行并使补丁无法使用。我也尝试设置 fetchmail 和 mutt，但经过 10 个小时的阅读和尝试后，我放弃了。是否有用于发送 git 补丁的非 fetchmail 和非 Thunderbird 解决方案？

我正在努力为在行尾包含一些 ^M 的文件创建补丁。当我编辑文件时，我没有看到 ^M，但是由 format-patch 创建的补丁确实在补丁区域上下文中指出了它。因此，当我尝试将其应用于新的 git 树时，git am 正在行尾搜索此 ^M 但没有看到它；它是错误的结果。

git format-patch 有什么想法或解决方法可以停止考虑这个 ^M 吗？

提前致谢

PS：对于上下文，我对这个 git 树没有写权限，这就是我需要打补丁的原因。

我们在两个分支中维护我们应用程序的两个版本：free和master（master是我们应用程序的高级版本）。这些分支非常相似，但是该master分支有一些free版本没有的额外应用程序功能，因此我们需要保持这两个分支持续运行。

定期我们需要修复错误或向free分支添加功能，我们需要在完成后将其应用到master分支。当我有这样的工作要做时，我会开始一个基于free调用的新分支，例如newfeature. 当我完成这个功能时，newfeature有 X 个新的提交。

在我newfeature重新合并之前，free我想知道我可以使用什么命令从newfeature现在需要应用到的所有提交中生成补丁master。目前，我只是这样做：

据我所知，我必须实际查找分支时的具体提交 ID newfeature，以及最后一次提交newfeature，这是一个拖累。我对提交 ID 不感兴趣，我不想输入它们。

我希望有一个我可以持续使用的命令，git 将找出我正在谈论的提交。每次都是相同的模式：给定分支newfeature，我想生成一个从共同祖先newfeature到free最新提交newfeature的提交补丁。

是否有一些变更集表达式可以避免手动查找提交 ID 的需要？

PS：AFAIK，我不能git rebase用来执行此任务，因为这会将整个free分支合并到master. 我只想将newfeature分支独有的提交合并到master.

我需要为我们的审查过程获取初始提交的补丁文件（不为空），但我很困惑，因为git format-patch命令只从初始提交的分支中生成，不包括它。

似乎这一定是一些明显的举动，但我完全想念它。