java - git 检测到我们 Java 项目中的重命名/移动很差 - 怎么办？

Question

我读过很多关于 git 如何巧妙地检测文件何时被重命名或移动的文章，您不必(或不能)做任何事情来帮助它完成此类任务。不幸的是，我们的项目中有很多问题，在文件移动后，git 历史记录将由一行组成。这是从我最近看到的一个例子中提取的模式:

原始类:

package a.b.c.d.e.f.X;

[four imports]

public interface A extends B {
  void f(String id, int index) throws MyException;

  @Annotation
  class AImpl extends C implements A {
    @OtherAnnotation
    public void f(String id, int index)
      throws MyException {
        Map<String, Object> inputs = new HashMap<String, Object>();
        inputs.put("a", id);
        inputs.put("b", index);
        execute(inputs);
    }

    @Override
    public String g() {
      return "xxxx.yyyy";
    }
  }
}

移动后的类:

package a.b.c.d.e.f.Y;

[six imports, two new compared to original]

public interface A extends B {
  void f(MyIdObject idobject, int index) throws MyException;

  @Annotation
  class AImpl extends D implements A {
    @OtherAnnotation
    public void f(@ParameterAnnotation([some stuff]) MyIdObject idobject, int index) throws MyException {
        Map<String, Object> inputs = new HashMap<>();
        inputs.put("c", idobject.getId());
        inputs.put("b", index);
        execute(inputs);
    }

    @Override
    public String g() {
      return "yyyy";
    }
  }
}

总而言之:类文件被移动到另一个目录/包(不同级别 - 请参阅包名称)，添加了导入，在此处声明和实现的方法中更改了参数，删除了换行符方法头，方法内部更改了一个字符串，HashMap 实例化更改为使用菱形表示法，g() 中的返回值更改。

大多数标识符和字符串都已更改以保护无辜者 - 它们通常为 10-20 个字符。我还没有编译这个，如果有任何错误，我深表歉意 - 我希望你明白这一点。

因为这是一些框架重构的一部分，所以在同一个提交中有一堆类按照这种模式进行了更改，不同之处在于字符串内容、散列图中的字符串数量以及“f”方法名称.

所以我想我可以看到 git 在这里挣扎的地方 - 尽管这个特定的重命名本身很明显，但当它与具有相似内容的文件的其他重命名混合在一起时，git 无法确定哪个是哪个？文件名(未更改)不应该足够提示吗？

我的印象是，既然 git 应该可以完美地处理这个问题，那么没有办法调整 git 以更好的方式处理这个问题吗？当我们重构以使其更好地工作时，我们可以做些什么吗？我们现在可以做点什么吗？

特别是:我希望能够在每次提交中看到文件的差异，包括完成重命名的那个。我习惯于在 IntelliJ 中加载 git 历史记录，他双击一个提交，这将向我显示该提交中所做的更改。我知道在 IntelliJ 中可能无法获得我想要的东西，但对于一个历史记录如此中断的文件，我该如何在命令行或其他地方做到这一点？

我们可能不想做的事情:1) 每次重命名一次提交，2) 一次重命名提交 + 另一次内容更改提交。

如果您对 Java 设计感到好奇，请给我发私信 - 让我们继续讨论 git。 :)

Answer 1

尝试使用这些额外的 git log --follow <filename> options :

-M[]

--find-renames[=]

If generating diffs, detect and report renames for each commit. For following files across renames while traversing history, see --follow. If n is specified, it is a threshold on the similarity index (i.e. amount of addition/deletions compared to the file’s size). For example, -M90% means git should consider a delete/add pair to be a rename if more than 90% of the file hasn’t changed. Without a % sign, the number is to be read as a fraction, with a decimal point before it. I.e., -M5 becomes 0.5, and is thus the same as -M50%. Similarly, -M05 is the same as -M5%. To limit detection to exact renames, use -M100%.

-C[]

--find-copies[=]

Detect copies as well as renames. See also --find-copies-harder. If n is specified, it has the same meaning as for -M.

--find-copies-harder

For performance reasons, by default, -C option finds copies only if the original file of the copy was modified in the same changeset. This flag makes the command inspect unmodified files as candidates for the source of copy. This is a very expensive operation for large projects, so use it with caution. Giving more than one -C option has the same effect.