git-deps 1.1.0

内容

• 背景理论

• 动机

  • 用例1：分支间的迁移

  • 用例2：将补丁系列拆分为独立主题

  • 用例3：协助协作沟通

  • 用例4：自动合并fixup提交

  • 用例5：重写提交历史

• 安装

• 使用方法

• 文本与语义（不）独立性

• 开发/支持/反馈

• 历史

• 致谢

• 许可协议

背景理论

从某种意义上来说，在单个仓库中，如果两个Git提交没有修改相同的文件，或者没有修改同一文件的重叠部分，那么这两个提交在某种程度上可以被认为是“独立的”。

相比之下，当一个提交修改了一行时，它不仅“依赖于”最后修改该行的提交，还依赖于任何负责提供上下文行（即前一个版本中的该行及其上下文）的提交，因为没有这些之前的版本和上下文，该提交的diff可能无法干净地应用（当然，这取决于应用的方式）。因此，一个提交的所有依赖都可以通过运行git-blame对其修改的行以及与特定依赖分析用例相关的上下文行进行程序性推断。

因此，依赖计算受一个“模糊”参数的影响，即“fuzz”参数（参见patch(1)），即考虑为提交的diff干净应用所必需的上下文行数。

正如许多依赖关系一样，这些依赖关系形成了一个DAG（有向无环图）的边，其节点对应于提交。请注意，一个节点只能依赖于其祖先的一部分。

动机

有时了解这个依赖图的部分性质是有用的，因为它的性质将影响包括合并、变基、 cherry-pick等操作的成功或失败。有关详细信息，请参阅``USE-CASES.md`文件 <USE-CASES.md>`__。

安装

请参阅``INSTALL.md`文件 <INSTALL.md>`__。

使用方法

请参阅``USAGE.md`文件 <USAGE.md>`__。

文本与语义（不）独立性

敏锐的读者会注意到，由git-deps检测到的文本独立性不等于语义/逻辑独立性。文本独立性意味着更改可以在任何顺序下应用而不会产生冲突，但这并不是逻辑独立性的可靠指标。

例如，对一个函数的更改以及该函数的测试和/或文档的相应更改通常存在于不同的文件中。因此，如果这些更改在分支的单独提交中，运行git-deps在提交上不会检测到它们之间的任何依赖，尽管它们在逻辑上是相关的，因为不同文件（甚至在同一文件的不同区域）的更改在文本上是独立的。

因此，在这种情况下，git-deps的行为可能并不完全符合我们的期望。只要AI是一个未解决的问题，它就不太可能发展出完全可靠的性能。那么这意味着git-deps是无用的吗？绝对不是！

首先，当遵循提交结构最佳实践和提交结构时，逻辑上紧密相关的更改应该放在同一个提交中。因此，在上面的例子中，对一个函数的更改以及该函数的测试和/或文档的相应更改都应该在单个提交中。尽管这不是唯一的有效方法；对于更高级的元历史分组机制，请参阅`git-dendrify<https://github.com/bennorth/git-dendrify>`__。

其次，虽然文本独立性并不一定意味着逻辑独立性，但相反的情况可能更为常见：逻辑独立性通常意味着文本独立性（或者说，文本依赖通常意味着逻辑依赖）。因此，虽然git-deps无法检测到逻辑相关更改之间的依赖性可能并不罕见，但错误地推断逻辑无关更改之间的依赖性应该更为罕见。换句话说，其假阴性通常比假阳性更常见。因此，它更有可能在确定依赖性的下限方面比上限更有用。尽管如此，还需要对此进行更多研究。

第三，允许追求完美成为优秀的敌人——一个工具不需要完美才能有用；它只需要比不使用工具执行相同任务更好。

关于这些观点的一些进一步讨论可以在git邮件列表的一个旧帖子中找到。

然而，最终，“实践是检验真理的唯一标准”，所以试试看吧！

开发/支持/反馈

请参阅`CONTRIBUTING.md`文件。

历史

请参阅`HISTORY.md`文件。

致谢

特别感谢SUSE部分赞助此软件的开发。还要感谢所有贡献代码、错误报告和其他反馈的人。

许可协议

在遵循`git`的许可证（https://github.com/git/git/blob/master/COPYING）的同时，以GPL版本2发布，以便保持一致性，但我愿意考虑如果存在令人信服的理由，可以采用双重许可。