同意@Raymond Chen（对您上面的问题的评论），当更改“恢复”时哈希“恢复”，并且可以在不提交的情况下生成哈希。
但是，恕我直言，对“版本”或“日期”进行哈希处理的最重要原因是为了避免冲突，多个开发人员可能正在工作，但不共享“集中式服务器”来协调修订号更新，或解决意外时间冲突。
例如：
如果两个开发人员想同时进行更改，更新“时间戳”是不明确的（但哈希不是）。
如果两个开发人员正在工作但不共享一个中央“版本号服务器”（例如，其中一个是“离线”），那么更新版本号是不明确的（因为两者都会要求下一个版本号） ，但散列不是模棱两可的。
“分布式”模型是 git/mercurial 转向“哈希”的原因，以放弃对中央版本号服务器的需求。
在您的特定情况下，如果您是唯一的开发人员，您可能会争辩说您不需要这个“reconcile-from-distributed-changes”功能。但是，当您分叉/分支然后合并时，版本号会变得混乱/不明确。
Subversion 通过单调递增整个存储库的单个数字来处理此问题，但在您的用例中，您正在谈论每个文件的版本号。以前的版本控制系统（如cvs、rcs、sccs等）通过为每个分支/合并“添加”一个“计数器”来处理每个文件的版本号。这些数字变得复杂，并且仍然导致模棱两可。例如，存储库中的一个文件可能具有类似 的版本，2.3.27另一个可能具有3.2，另一个可能26同时具有在不同的分支上（它变得混乱）。例如，2.4.12.37.2MyFileA.txt被分支/合并了很多，如果两个文件意外地具有相同的版本26（对于一个文件，它是几年前在二十个分支/合并之前，而对于另一个文件，那是当前版本）。