使用git删除函数及其docblock时如何创建适当的补丁 [英] How to create a proper patch when removing a function and its docblock with git

问题描述

当您在多个功能之上具有文档块时，删除功能会创建次优补丁.

When you have docblocks above multiple functions removing a function creates a sub-optimal patch.

index.js:

/**
 * Function foo description.
 */
function foo() {}

/**
 * Function bar description.
 */
function bar() {}

使用其docblock删除函数foo会生成以下补丁:

Removing function foo with its docblock generates the following patch:

diff --git a/index.js b/index.js
index f4e18ef..933004f 100644
--- a/index.js
+++ b/index.js
@@ -1,9 +1,4 @@
 /**
- * Function foo description.
- */
-function foo() {}
-
-/**
  * Function bar description.
  */
 function bar() {}

这意味着伴随它的任何合并提交都将触及函数foo和功能栏之间的空格，这将导致冲突. 例如，假设我们在删除foo之前创建了一个分支feature-1，并在index.js中在两者之间添加了一个函数foobar.冲突如下所示:

This means that any merge that brings with it commits that touch the space between function foo and function bar now result in a conflict. For example imagine we created a branch feature-1 before removing foo, and in index.js added a function foobar between the two. The conflict would look as follows:

/**
<<<<<<< HEAD
=======
 * Function foo description.
 */
function foo() {}

/**
 * Function foobar description.
 */
function foobar() {}

/**
>>>>>>> feature-1
 * Function bar description.
 */
function bar() {}

我想如果/**是从顶部抓起的，那不会有问题.我确信git有充分的理由更喜欢从结尾处删除，但我想强迫它从一开始就抓住它.有没有一种方法可以轻松地做到这一点?还是手动补丁编辑是唯一的方法?

I imagine there would be no issue if the /** was grabbed from the top instead. I'm sure there's a good reason for git to prefer removing from the end but I'd like to force it to grab it from the start. Is there a way to easily do this? Or is manual patch editing the only way?

推荐答案

它远非完美，但Git 2.9中新的--compaction-heuristic通常可以满足您的需求.有关详细信息，请参见此博客文章.您可以将其配置为默认情况下处于启用状态，但是由于有时它会使情况变得更糟，因此我没有这样做:

It's far from perfect, but the new --compaction-heuristic in Git 2.9 often does what you want. See this blog post for details. You can configure it to be on by default, but given that it sometimes makes things worse, I have not done so:

git config --global diff.compactionHeuristic true

您的Git版本必须至少为2.9，才能生效.

Your Git version must be at least 2.9 for this to have any effect.

当前实现中的一个缺陷是，从字面上看，它需要在修改后的部分上方留空行.仅从文件顶部开始是不够的.例如，假设我们从以下开始:

One flaw in the current implementation is that it quite literally requires a blank line above the modified section. Starting at the top of the file is not sufficient. For instance, suppose we start with:

block:
This file has
three blocks.

block:
There is a blank line
between each.

block:
This is the third
block.

如果我们删除 middle 块，则默认的diff将保留第二条block:行，并删除第三条block:行.启用压缩将使diff大块向上移动，直到它到达第二个block:上方的空白行，这就是我们想要的.

If we delete the middle block, the default diff retains the second block: line and deletes the third block: line. Turning on compaction moves the diff hunk up until it reaches the blank line above the second block:, which is what we want.

不幸的是，如果我们删除 first 块，则压缩启发式尝试将diff块向上移动以包括第一block:行，但是失败，因为它到达了文件的顶部，它上面没有空行(因为它上面根本没有行).因此，它将第一个单词block:留在原处，并删除第二个单词.

Unfortunately, if we delete the first block, the compaction heuristic attempts to move the diff hunk up to include the first block: line, but fails because it hits the top of the file, where there is no blank line above it (as there is no line at all above it). It therefore leaves the first word block: in place and deletes the second.

(修复此问题只需要压缩算法提供一个空白的虚拟行零".请注意，由于默认差异有利于删除后面的行，因此问题本身永远不会出现在文件末尾.丑陋的解决方法是在每个文件的顶部保留一个空白行，以使压缩可以看到它.)

(Fixing this would require only that the compaction algorithm provide a "virtual line zero" that is blank. Note that the problem itself never occurs at the end of the file since the default diff favors deletion of later lines. Meanwhile, an ugly workaround is to leave a blank line at the top of each file, just so that compaction can see it.)

这篇关于使用git删除函数及其docblock时如何创建适当的补丁的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！