(我已经接受了Roland的答案,因为它确实是从git 1.7.4.4开始的正确(也是最简单的)解决方案,但请考虑这个问题,关于git的早期版本低至1.7.0.4.)
这个问题有点散漫(主要是由于我后来尝试建立有关情况的更多信息所导致的编辑),但标题中的文字是最重要的一点.
那就是:我正在尝试建立确定所有 git命令将在其输出中显示完整(未缩写)哈希的确定方法.
由于我专注于向后兼容性,因此需要涵盖旧版本的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,但我不知道这两个命令是否是孤立的情况,我想确保在其他情况下不会出现这个问题.
我能看到的唯一相关配置是core.abbrev:
设置长度对象名称缩写为.如果未指定,则许多命令缩写为7个hexdigits,这可能不足以使缩写的对象名称在足够长的时间内保持唯一.
(但我不想删除看到缩写提交的选项),以及
log.abbrevCommit:
如果为true,则生成git-log(1),git-show(1)和git-whatchanged(1)
--abbrev-commit.您可以使用覆盖此选项--no-abbrev-commit.
--no-abbrev-commit尽管如此,这个论点并不是一致的 - 我认为只有该引用中提到的命令才能识别它(但请参见下面的编辑2).
开始编辑2
在解析选项API文档的状态:
布尔长选项可以通过前置,例如 代替而取消(或取消设置).相反,开头的选项 可以通过删除它来取消.
no---no-abbrev--abbrevno-
那么接受--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命令(包括将来的 命令)尊重,但保持显示缩写的能力哈希值何时需要？
我遇到的一个丑陋的方法是创建一个导入原始配置文件的git配置文件
(虽然我注意到导入只能从1.7.10开始),然后设置core.abbrev为40; 并且GIT_CONFIG在调用git时通过临时环境变量使用它,只要完全提交是必需的.我想这会奏效,但我宁愿不这样做.
显然有错误,至少有一些错误已被修复; 但是由于目标是支持用户可能合理地运行的git(实际)版本,我正在寻找一些向后兼容的东西.
对于它的价值,这是我从grept 1.7.12.4版本的手册中收集到的内容:
命令接受--abbrev(因此理论上也是--no-abbrev):
其他选择:
Rol*_*ith 16
使用git -c core.abbrev=40 <command>应该适用于所有命令,因为它"将覆盖配置文件中定义的任何内容".
它似乎已经被引入8b1fa778676ae94f7a6d4113fa90947b548154dd(在1.7.2版本中登陆).
编辑2:正如phils注意到的,该core.abbrev参数在1.7.4.4中添加.
编辑:Wrt硬编码哈希长度,您可以通过查看.git/objects/*初始化程序/库时的文件名长度来查找哈希长度.