Tig项目中的blame视图行号跳转问题分析与修复

在版本控制工具Tig 2.5.12中，用户发现blame视图存在一个行号跳转不准确的问题。当用户在blame视图中尝试跳转到某行的原始提交时，系统会错误地跳转到目标提交中相同行号的位置，而非该行实际对应的位置。

问题现象

具体表现为：在Tig仓库中执行tig blame +28 tig-2.5.12 -- src/diff.c命令后，按下b键试图跳转到该行的原始提交时，系统会错误地跳转到目标提交的第28行，而实际上应该跳转到第54行。这是因为文件在不同版本间发生了内容增减，导致行号发生了变化。

技术背景

在Git版本控制系统中，blame功能用于追溯文件中每一行最后一次被修改的提交。当文件在历史版本中被修改（特别是添加或删除了行）时，行号会发生变化。因此，正确的blame跳转应该考虑这些行号变化，跳转到目标提交中实际对应的行位置，而非简单地使用当前行号。

问题根源

这个问题是在修复另一个问题(#973)时引入的，具体出现在提交ca0809dbd中。修复前的版本行为是正确的，但在那次修改后，行号跳转逻辑出现了偏差，导致系统不再考虑文件历史版本间的行号变化。

解决方案

修复方案需要重新审视blame视图的行号跳转逻辑，确保在跳转时能够正确计算目标提交中的对应行号。这需要：

1. 正确解析blame输出中的原始行号信息
2. 在跳转时使用原始行号而非当前行号
3. 确保与Git的blame机制保持一致性

影响评估

这个问题会影响所有使用blame视图并尝试跳转到原始提交的用户。特别是在文件历史中有大量修改的情况下，错误的行号跳转会严重影响代码审查和历史追溯的效率。

修复验证

修复后，用户可以通过以下步骤验证问题是否解决：

1. 对有明显行号变化的文件执行blame操作
2. 尝试跳转到不同行的原始提交
3. 确认跳转后的行号确实对应原始修改位置

这个问题提醒我们，在修复一个bug时，需要全面考虑可能影响的相关功能，特别是涉及核心功能如blame时，更需要谨慎处理。