使所有命令的git输出都完整(未缩写)散列? [英] Making git output full (un-abbreviated) hashes for all commands?

查看：38 发布时间：2020/11/15 2:51:25 git

本文介绍了使所有命令的git输出都完整(未缩写)散列?的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

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

(n.b. I've accepted Roland's answer, as it is indeed the correct (and simplest) solution starting from git 1.7.4.4, but please consider this question open regarding earlier versions of git down to 1.7.0.4.)

这个问题有点儿杂乱无章(主要是由于我的随后尝试建立有关情况的更多信息)，但标题中的文字是最重要的部分.

This question is a bit rambling (primarily due to the edits resulting from my subsequent attempts to establish more information on the situation), but the text in the title is the most important bit.

也就是说:我正在尝试确定一种确定方法，以确保全部 git 命令将在其输出中显示完整(未缩写)的哈希.

That is: I'm trying to establish the definitive way to ensure that all git commands will display full (un-abbreviated) hashes in their output.

由于我专注于向后兼容，因此需要涵盖较旧的版本 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)绝对不理想，但我还是很想听听关于他们.

As I am focussed on backwards-compatibility, this needs to cover older versions of git 1.7. Ideally the solutions would work for git 1.7.0.4 (which is used in the still-supported Ubuntu 10.04 LTS), but I'd be happy with a minimum of 1.7.2.5 (for Debian 6 / Squeeze LTS). Anything requiring a version later than 1.7.9.5 (Ubuntu 12.04 LTS) is definitely not ideal, but I'd still love to hear about them.

请注意，我不希望失去功能并具有简短的哈希值 -这个问题的目的是确保工具与git交互始终可以访问完整且明确的哈希.当我手动使用git时在大多数情况下，我通常需要使用命令行缩写.

Please note that I do not wish to lose the ability to have abbreviated hashes -- the purpose behind this question is to ensure that tools interacting with git can always access a complete and unambiguous hash. When I use git manually on the command line I am going to want the normal abbreviations most of the time.

罗兰·史密斯(Roland Smith)的建议是使用命令行参数覆盖 core.abbrev看起来很理想，但可悲的是仅从v1.7.4.4起可用(如core.abbrev 以前不存在).我怀疑，这意味着我们需要确定最全面的命令特定参数集(例如git blame -l) 产生等效的效果.

Roland Smith's suggestion of utilising a command-line argument override for core.abbrev looked ideal, but sadly only works since v1.7.4.4 (as core.abbrev did not previously exist). I suspect this means we do need to determine the most comprehensive set of command-specific arguments (such as git blame -l) to produce the equivalent effect.

一些(最多?)git命令 default 可以输出缩写哈希.为了实例git blame和git-annotate都执行了此操作，而这个事实在跳闸发生冲突时，提高当前的Emacs支持(就像他们在git之前所做的那样) 1.7.11.1-请参阅下面的编辑1)，因为模棱两可的哈希值会在以下情况下导致错误: 试图对他们采取行动.

Some (most?) git commands default to outputting abbreviated hashes. For instance both git blame and git-annotate do this, and this fact was tripping up the current Emacs support when clashes arose (as they can do prior to git 1.7.11.1 -- see Edit 1 below), as the ambiguous hashes then caused errors when attempting to act upon them).

开始编辑1

我在Changelog中注意到以下内容，这表明原始问题提示此问题的问题不会在更高版本的 git.

I note the following in the Changelog, which suggests that the original problem which prompted this question issue would not arise in more recent versions of 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早期版本的问题仍然是兴趣.

If it's the case that git is supposed to guarantee uniqueness (at least at the time the command is run) for all object names reported by any git command, then that would significantly alleviate my concerns; but obviously a solution to the question which supports earlier versions of git is still going to be of interest.

结束编辑1

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

That can be fixed with git blame -l and git annotate -l, but I don't know whether these two commands are isolated cases or not, and I want to ensure that this issue can't arise in other situations.

唯一相关的配置见core.abbrev:

设置长度对象名称的缩写.如果未指定，则许多命令缩写为7个十六进制数字，可能不足以代表缩写对象名称可以在足够长的时间内保持唯一性.

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.

(但是我不想删除看到缩写提交的 option )，并且 log.abbrevCommit其中:

(but I don't want to remove the option of seeing an abbreviated commit), and log.abbrevCommit which:

如果为true，则假设git-log(1)，git-show(1)和git-whatchanged(1) --abbrev-commit.您可以使用--no-abbrev-commit覆盖此选项.

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 下面).

The --no-abbrev-commit argument isn't a consistent thing, though -- I presume that only the commands mentioned in that quote recognise it (but see Edit 2 below).

开始编辑2

解析选项API文档状态:

可以通过在no-之前加上>来使
布尔型长选项取反(或取消设置). --no-abbrev代替--abbrev.相反，以no-开头的选项可以通过否定将其删除.

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当前等效，即使没有否定可用).

So the commands which accept --abbrev (of which there are many) will in fact all accept --no-abbrev as well? This negated option is often not mentioned; although --abbrev=40 would currently be equivalent, of course, even if no negation was available).

我不清楚默认的布尔否定选项功能何时为但是，介绍了.

It's not clear to me when the default boolean negation option feature was introduced, however.

在我的1.7.9.5版本中，git-blame --no-abbrev结果为单个字符对象名称.实际上，它与--abbrev=0相同，因为责备使用n+1字符. 相反，我注意到git branch -v --abbrev=0给出了全部40 字符.

In my version 1.7.9.5 git-blame --no-abbrev results in single-character object names. In fact it's the same as --abbrev=0, as blame uses n+1 characters. Conversely I notice that git branch -v --abbrev=0 gives the full 40 characters.

结束编辑2

的潜在问题的命令与其相应的选项的完整列表将是极好的，尽管理想的解决方案是 (或至少应该)被所有git命令(包括 future 命令)，但是可以在需要时保持显示缩写哈希的功能?

A complete list of the potential problem commands with their appropriate options would be excellent, although the ideal solution would be something that would (or at least should) be respected by all git commands (including future commands), but maintains the ability to display abbreviated hashes when desired?

我想到的一个丑陋的方法是创建一个git配置文件，该文件 imports 原始配置文件(尽管我注意到导入仅从1.7.10开始可用)，然后将core.abbrev设置为40；并通过一个调用git时的临时GIT_CONFIG环境变量，只要已满提交是必要的.我想这会起作用，但我宁愿不这样做.

An ugly approach which occurred to me was to create a git config file which imports the original config file (although I note that importing is only available from 1.7.10) and then sets core.abbrev to 40; and to use this via a temporary GIT_CONFIG environment variable when invoking git, whenever full commits are a necessity. I guess this would work, but I'd rather not do it.

很显然，这里有/是一些错误，并且至少从那时起，有些错误就已经存在了. 固定的;但目的是要支持尽可能多(尽可能实际)的git版本用户可能恰巧正在运行，我正在寻找向后兼容.

Clearly there are/were bugs, and some of the bugs at least have since been fixed; but as the aim is supporting as many (as practical) versions of git that a user might reasonably happen to be running, I'm looking for something which is backwards-compatible.

对于它的价值，这是我从grep的手册中收集到的内容版本1.7.12.4:

For what it's worth, here's what I've gleaned from grepping the manual for version 1.7.12.4:

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

Commands accepting --abbrev (and thus in theory also --no-abbrev):

怪
分支
cli
描述
差异
差异索引
差异树
日志
ls文件
ls-tree
rev-list
rev-parse
显示参考

blame
branch
cli
describe
diff
diff-index
diff-tree
log
ls-files
ls-tree
rev-list
rev-parse
show-ref

其他选项:

git注释-l
git blame -l </li>
git diff --full-index
git log --no-abbrev-commit
git show --no-abbrev-commit
git whatchanged --no-abbrev-commit

git annotate -l
git blame -l
git diff --full-index
git log --no-abbrev-commit
git show --no-abbrev-commit
git whatchanged --no-abbrev-commit

使所有命令的git输出都完整(未缩写)散列? [英] Making git output full (un-abbreviated) hashes for all commands?

问题描述

推荐答案

相关文章

其他开发最新文章

热门教程

热门工具

登录关闭

使所有命令的git输出都完整(未缩写)散列? [英] Making git output full (un-abbreviated) hashes for all commands?

问题描述

推荐答案

相关文章

其他开发最新文章

热门教程

热门工具

登录 关闭

登录关闭