问题更新
（注意：我已经接受了罗兰的回答，因为它确实是正确的（并且
最简单）从 git 1.7.4.4 开始的解决方案，但请考虑这个问题
打开有关 git 低至 1.7.0.4 的早期版本的信息。）
这个问题有点漫无目的（主要是由于我的编辑造成的）
随后尝试建立有关情况的更多信息），但
标题中的文字是最重要的部分。
也就是说：我正在尝试建立明确的方法来确保allgit
命令将在其输出中显示完整（未缩写）的哈希值。
由于我专注于向后兼容性，因此需要覆盖旧版本
git 1.7 的。Ideally该解决方案适用于 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）绝对不理想，但我仍然很想听听
关于他们。
请注意，我不想失去ability有缩写的哈希值
-- 这个问题背后的目的是确保工具与 git 交互
始终可以访问完整且明确的哈希值。当我手动使用 git 时
在命令行中，我大部分时间都需要正常的缩写。
Roland Smith 关于利用命令行参数覆盖的建议core.abbrev看起来很理想，但遗憾的是只能从 v1.7.4.4 开始工作（如core.abbrev以前不存在）。我suspect这意味着我们确实需要确定
最全面的命令特定参数集（例如git blame -l）
才能产生同等的效果。
带有编辑的原始问题
一些（大多数？）git 命令default输出缩写的哈希值。为了
实例两者git blame and git-annotate这样做，这个事实正在绊倒
当发生冲突时提高当前的 Emacs 支持（就像他们在 git 之前可以做的那样）
1.7.11.1 - 请参阅下面的编辑 1），因为不明确的哈希值随后会导致错误
试图对它们采取行动）。
开始编辑1
我在变更日志中注意到以下内容，这表明最初的问题
这促使这个问题在更新的版本中不会出现
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 and git annotate -l，但我不知道
这两个命令是否是孤立的情况，我想确保
在其他情况下不会出现此问题。
唯一相关的配置 https://www.kernel.org/pub/software/scm/git/docs/git-config.html我可以看到是core.abbrev:
设置对象名称缩写的长度。如果未指定，则有许多命令
缩写为 7 个十六进制数字，这对于缩写对象来说可能不够
名称在足够长的时间内保持唯一。
（但我不想删除option看到一个简短的提交），以及log.abbrevCommit which:
如果为 true，则使 git-log(1)、git-show(1) 和 git-whatchanged(1) 假设--abbrev-commit。您可以使用以下命令覆盖此选项--no-abbrev-commit.
The --no-abbrev-commit不过，争论并不是一致的——我认为
只有该引用中提到的命令才能识别它（但请参阅编辑 2
以下）。
开始编辑2
The 解析选项 API 文档 https://www.kernel.org/pub/software/scm/git/docs/technical/api-parse-options.html states:
布尔长选项可以是negated (or unset）通过前置no-，例如--no-abbrev代替--abbrev。相反，以no-可negated通过删除它。
所以接受的命令--abbrev（其中有很多）实际上会
全部接受--no-abbrev还有？这个否定选项通常不会被提及；
虽然--abbrev=40当然，目前是等价的，即使没有
可以否定）。
我不清楚默认的布尔否定选项功能是什么时候
然而，介绍了。
在我的版本1.7.9.5中git-blame --no-abbrev结果为单字符对象
名称。事实上它是一样的--abbrev=0，正如指责使用的那样n+1人物。
相反，我注意到git branch -v --abbrev=0给出满分 40
人物。
结束编辑2
潜在问题命令及其相应选项的完整列表
会很棒，尽管理想的解决方案是
（或者至少应该）受到所有 git 命令的尊重（包括future命令），但仍保留在需要时显示缩写哈希的能力？
我想到的一个丑陋的方法是创建一个 git 配置文件imports原始配置文件（尽管我注意到导入只是
从 1.7.10 开始可用），然后设置core.abbrev至 40；并通过使用它
暂时的GIT_CONFIG调用 git 时的环境变量，只要已满
提交是必要的。我想这会起作用，但我宁愿不这样做。
显然存在错误，并且其中一些错误至少已经被解决了
固定的;但由于目标是支持尽可能多（尽可能多）的 git 版本
用户可能碰巧正在运行，我正在寻找的东西是
向后兼容。
对于它的价值，这是我从 grep 手册中收集到的内容
版本1.7.12.4：
接受命令--abbrev（因此理论上也--no-abbrev):
- blame
- branch
- cli
- describe
- diff
- 差异索引
- 差异树
- log
- ls-files
- ls-tree
- rev-list
- 转解析
- show-ref
其他选项：
- git注释-l
- git 责备-l
- git diff --完整索引
- git log --no-abbrev-commit
- git show --no-abbrev-commit
- git Whatchanged --no-abbrev-commit
