git - 为所有命令制作 git 输出完整(非缩写)哈希？

Question

问题更新

(n.b. 我已经接受了 Roland 的回答，因为它确实是正确的(并且
最简单的)解决方案从 git 1.7.4.4 开始，但请考虑这个问题
将早期版本的 git 降低到 1.7.0.4。)

这个问题有点乱(主要是由于我的
随后试图确定更多有关情况的信息)，但
标题中的文字是最重要的一点。

那就是:我正在尝试建立确定的方法来确保 全部 混帐
命令将在其输出中显示完整的(未缩写的)哈希值。

由于我专注于向后兼容性，因此需要涵盖旧版本
git 1.7。理想情况下，这些解决方案适用于 git 1.7.0.4(用于
仍然支持的 Ubuntu 10.04 LTS)，但我会很高兴至少有
1.7.2.5(适用于 Debian 6/Squeeze LTS)。任何需要版本晚于
1.7.9.5 (Ubuntu 12.04 LTS) 绝对不理想，但我还是很想听听
关于他们。

请注意，我不希望失去使用缩写哈希的能力
-- 这个问题背后的目的是确保工具与 git 交互
始终可以访问完整且明确的哈希。当我手动使用 git 时
命令行 我大部分时间都需要正常的缩写。

Roland Smith 建议使用命令行参数覆盖core.abbrev看起来很理想，但遗憾的是只适用于 v1.7.4.4(如 core.abbrev以前不存在)。我怀疑这意味着我们确实需要确定
最全面的特定于命令的参数集(例如 git blame -l )
以产生等效的效果。

带有编辑的原始问题

一些(大多数？)git 命令默认输出缩写的哈希值。为了
两个实例 git blame和 git-annotate这样做，这个事实令人震惊
发生冲突时提高当前的 Emacs 支持(就像他们可以在 git 之前做的那样)
1.7.11.1 - 请参阅下面的编辑 1)，因为不明确的散列然后导致错误
试图对他们采取行动)。

开始编辑 1

我在 Changelog 中注意到以下内容，这表明原始问题
导致这个问题的问题在最近的版本中不会出现
git 。

Fixes since v1.7.11.1
---------------------
 * "git blame" did not try to make sure that the abbreviated commit
   object names in its output are unique.

如果 git 应该保证唯一性(至少在
运行命令时)对于任何 git 命令报告的所有对象名称，然后
这将大大减轻我的担忧；但显然是一个解决方案
支持早期版本 git 的问题仍然是
兴趣。

结束编辑 1

这可以通过 git blame -l 修复和 git annotate -l ，但我不知道
这两个命令是否是孤立的情况，我想确保
在其他情况下不会出现此问题。

唯一相关configurations我能看到的是core.abbrev :

Set the length object names are abbreviated to. If unspecified, many commands abbreviate to 7 hexdigits, which may not be enough for abbreviated object names to stay unique for sufficiently long time.

(但我不想删除查看缩写提交的选项)，并且log.abbrevCommit哪一个:

If true, makes git-log(1), git-show(1), and git-whatchanged(1) assume --abbrev-commit. You may override this option with --no-abbrev-commit.

--no-abbrev-commit不过，争论并不是一致的——我想
只有该引用中提到的命令才能识别它(但请参阅编辑 2
以下)。

开始编辑 2

parse-options API document状态:

Boolean long options can be negated (or unset) by prepending no-, e.g. --no-abbrev instead of --abbrev. Conversely, options that begin with no- can be negated by removing it.

所以接受 --abbrev 的命令(其中有很多)实际上会
都接受--no-abbrev还有？这个否定的选项通常不被提及；
虽然 --abbrev=40目前当然是等价的，即使没有
否定可用)。

我不清楚默认的 bool 否定选项功能何时
然而介绍。

在我的版本 1.7.9.5 git-blame --no-abbrev结果是单字符对象
名称。其实和--abbrev=0是一样的，正如blame所用的n+1人物。
相反，我注意到 git branch -v --abbrev=0给出完整的 40
人物。

结束编辑 2

潜在问题命令的完整列表及其相应选项
会很好，虽然理想的解决方案是
(或至少应该)被所有 git 命令(包括 future
命令)，但保持在需要时显示缩写哈希的能力？

我想到的一个丑陋的方法是创建一个 git 配置文件
导入原始配置文件(虽然我注意到导入只是
从 1.7.10 开始可用)然后设置 core.abbrev到 40；并通过
临时GIT_CONFIG调用 git 时的环境变量，每当满时
提交是必需的。我想这会奏效，但我宁愿不这样做。

显然存在/曾经存在错误，并且其中一些错误至少已经存在
固定的;但因为目标是支持尽可能多的(尽可能多的)git版本
用户可能合理地碰巧正在运行，我正在寻找的东西
向后兼容。

对于它的值(value)，这是我从 grepping 手册中收集到的
版本 1.7.12.4:

接受命令 --abbrev (因此理论上也是 --no-abbrev ):

blame

分公司

cli

描述

差异

差异索引

差异树

日志

ls 文件

ls-tree

版本列表

rev解析

显示引用

其他选项:

git 注释 -l

git blame -l

git diff --full-index

git log --no-abbrev-commit

git show --no-abbrev-commit

git whatchanged --no-abbrev-commit

Answer 1

使用 git -c core.abbrev=40 <command>应该适用于所有命令，因为它“将覆盖配置文件中定义的任何内容”。

好像是在 8b1fa778676ae94f7a6d4113fa90947b548154dd 中引入的(登陆版本 1.7.2)。

Edit2:正如 phils 所注意到的，core.abbrev参数是在 1.7.4.4 中添加的。

编辑:W.r.t.硬编码的散列长度，您总是可以通过查看 .git/objects/* 中的文件名长度来查找散列长度。初始化程序/库时。