提交补丁开源项目

Question

我对拉入请求我对我在工作中使用一个相当大的开源项目做了一些困惑。我不会透露该项目，但它包含大量用户提交的脚本，用于监视关键任务系统或应用程序的各个方面。我发现了一个用户提交的shell脚本，我需要为自己的工作使用它，但它有几个主要的bug，并且风格上是一个残缺。我修复了这些bug，并重构了几乎整个脚本，使它变成了一个相当干净的“bash表单”。我没有对剧本一拉请求，项目负责人拒绝，报价补丁：

“这主要是编码风格改变你的努力是真的 赞赏，但如果我们开始，我们将不会取得任何接受补丁的那种 ，请尽量把注意力放在这个问题，即这确实 需要修复。感谢的东西！”

这里有一个bash编码风格变化的可读性我整个脚本制作的例子：

- start_time=`date +%s%N` 
+ start_time=$(date +%s%N) 

这是常见的开源项目？我承诺的大部分项目都是我自己的，我一直在重构风格不良的代码。如果代码将被其他人使用，例如有关脚本，那么是否应该重用可用性重构？我只是有点困惑，因为该项目没有编码风格指南。

Answer 1

每个项目都有自己的规则和准则。你被告知这个项目的工作原理与你工作的规则不同。如果你想贡献，这听起来像你必须遵守他们的规则。 （我往往是在辩论中你的身边 - 但是当我负责我不是，我被那些谁的规则去！）

Answer 2

你有没有分裂的补丁，这样的错误是第一个固定的，以后做出风格变化？如果不是，我也会拒绝这个补丁。一个改变逻辑的补丁应该尽可能的小而且独立。没有人希望通过几十种风格变化来确保它们在试图理解你所修复的内容时对逻辑没有影响。

Answer 3

这绝对不是开源项目中一个普遍的事情。我只举一个反例，从最近的拉要求：相关亩的Emacs的成分

https://github.com/djcb/mu/pull/65

我拉的请求，称mu4e。我唯一的变化是，使该项目有更多的变量可以通过M-x customize编辑（Emacs的相当于“编辑 - >首选项”，或“工具 - >选项”）。根本没有改变任何程序逻辑。正如你所看到的那样，在两个小时之后，pull请求就没有任何大惊小怪的合并了。 （之前我从未参与过这个项目，所以我没有根据过去的贡献或类似的方式进行快速跟踪）。所以这就是一个只有整体变化的拉动请求的例子，没有任何抱怨就很高兴地被接受。

至于为何有问题的项目拒绝你的补丁，也许他们只是固执或太骄傲了，让周围的其他人乱在他们的代码或类似的东西，但在另一方面，也有正当的理由不合并面向化妆品的非面向用户的更改。如果他们接受你的代码，并且他们至少是最低限度的责任人，他们将不得不至少查看你所做的所有更改，并确保你没有破坏某些东西，并确保你的代码更改与你的提交日志相匹配说你改变了。我猜你的pull请求在很多文件中改变了一大堆隔离的行或块，对吧？如果你用$()进行全面搜索并取代反引号，那么这可能就是最终结果。这种补丁可能很难验证，因为你在线后观察同样的变化，并且你的眼睛黯然失色，并且你错过了一个导致整个项目中断的近距离缺失的情况。

的一点是，即使你给他们的代码为免费，实际上是合并你的代码是不是免费的，参与你的代码集成到项目工作必须由谁运行该项目的人来完成，否则他们会合并他们不能信任的代码。在某些情况下，拥有该项目的人可能会考虑您的更改声称要改进的内容，并作出理性的决定，认为这些改进不足以以负责任的方式合并代码所需的努力。如果您不同意，您可以自由创建自己的分支（不是“敌对”分支，只是一个普通的“我的自定义项目X”分支），并将您的更改放在那里，然后自己使用它们。如果您的更改真的值得，人们可能会开始切换到您的分支，此时原始开发人员可能会重新考虑其位置并合并您的更改。