我有一个更大的Java代码库（~3000个类）的git repo，我想对整个代码库应用一个大的重组，这会将许多类移动到其他地方，重命名它们，并调整其他类中的引用因此。实际的代码转换是脚本化和经过充分测试的，我可以在几秒钟内运行它。
现在，当我提交整个内容时，git将显示许多已删除和新文件，因为移动文件的数量超过了某些重命名检测限制。这将使'git annotate'在未来变得无用，如果可能的话，我希望避免使用它。
如何进行重组，并保留有意义的文件历史记录？
答案 0 :(得分：1)
当Git从一个提交走到另一个提交并比较这两个树时，它会将所有“丢失”和“添加”的文件放入配对队列（然后确定在动态恢复问题上引发了多少CPU时间和内存）从不精确的文件匹配重命名 - 精确文件匹配非常快并缩小配对队列长度，从而减少此上限）。配对队列的最大长度为diff.renameLimit设置。
此默认值最初为100，然后在2008年（commit 50705915eae8，Git版本1.5.6）升至200，然后在2011年升至400（commit 92c57e5c1d29，Git版本1.7.5） 。它现在可能值得再加倍，但是如果你的Git至少是1.7.5，那么一次提交400个这样的重命名将保留对各个提交的重命名。
但请注意，这取决于Git检查相邻的提交，因此树中只有400个这样的更改。如果您直接从早期版本跳到较晚版本 - 例如，在git merge期间发生，或者如果您git diff是针对延迟版本的早期标记，则未配对文件名的数量可能会很多更大，因此溢出配对队列。 git merge的队列长度默认情况下较大，但仍不是3000。
您可以配置更高的重命名检测阈值。将diff.renameLimit设置为零意味着“尽可能使用最大值”：不完全没有限制，但最接近Git可以获得。