Git 符号引用的推荐用法是什么？

What's the recommended usage of a Git symbolic reference?

提问by nulltoken

The following shell code correctly creates a chain of symbolic references

以下 shell 代码正确创建了一个符号引用链

git symbolic-ref "first" "refs/heads/master"
git symbolic-ref "second" "first"
git symbolic-ref "nested/third" "second"
git symbolic-ref "refs/heads/fourth" "nested/third"

And the following shell code correctly resolves the latest created symbolic reference to the tip of master.

并且以下 shell 代码正确解析了最新创建的对 master 提示的符号引用。

git show-ref "refs/heads/fourth"

None of these use cases are described in the official documentation (git-symbolic-ref doc, git-show-ref doc).

官方文档（git-symbolic-ref doc，git-show-ref doc）中没有描述这些用例。

However, the following doesn't work

但是，以下不起作用

 git check-ref-format --print "first"

So, my questions are:

所以，我的问题是：

• Is it ok to store a symbolic reference within the refs/headsdirectory ?
• Is it ok to chain symbolic references ?
• As check-ref-format fails when being passed "first", does this mean that it's not recommended to create a symbolic reference at the same level than "HEAD"? Or maybe this command is not intended to deal with symbolic links ?

• 可以在refs/heads目录中存储符号引用吗？
• 链接符号引用可以吗？
• 由于 check-ref-format 在传递时失败"first"，这是否意味着不建议在与 相同级别创建符号引用"HEAD"？或者这个命令不是用来处理符号链接的？

My intent is to get a clear understanding of what is being supported and that I'm not working around anything or benefiting from a bug.

我的目的是清楚地了解支持的内容，并且我没有解决任何问题或从错误中受益。

采纳答案by nulltoken

I've eventually postedthis question to the git development mailing list.

我最终将这个问题发布到了 git 开发邮件列表。

Junio C Hamano, the lead git maintainer (+8700 commits) provided me with the following answers.

Junio C Hamano，首席 git 维护者（+8700 次提交）为我提供了以下答案。

There are only two valid kinds of symrefs right now:

• .git/HEAD, pointing at somewhere under refs/heads/ hierarchy;

• .git/refs/remotes/{some remote name}/HEAD, pointing at somewhere under refs/remotes/{the same remote name}/ hierarchy.

The code may be prepared to resolve recursive symrefs, symrefs other than the above two kinds, symrefs that point at elsewhere, but all of them are outside of the design scope of what the mechanism was intended to support. What the code do to them (without crashing) is not the design, but simply an undefined behaviour.

This won't change very much if we decide to reorganize the remote tracking hierarchies in 1.8.0. The former won't change at all, and the latter will start pointing at refs/remotes/{the same remote name}/heads hierarchy instead.

I vaguely recall tg abused the symref mechanism to point .git/HEAD at funny locations; it may still be doing so, and if that is the case we should extend the above list to cover that usage.

现在只有两种有效的 symrefs：

• .git/HEAD，指向 refs/heads/hierarchy 下的某处；

• .git/refs/remotes/{some remote name}/HEAD，指向refs/remotes/{相同的远程名称}/层级下的某处。

代码可能准备解决递归 symrefs，除上述两种以外的 symrefs，指向别处的 symrefs，但所有这些都超出了该机制旨在支持的设计范围。代码对它们所做的（没有崩溃）不是设计，而只是一种未定义的行为。

如果我们决定在 1.8.0 中重新组织远程跟踪层次结构，这不会有太大变化。前者根本不会改变，而后者将开始指向 refs/remotes/{相同的远程名称}/heads 层次结构。

我依稀记得 tg 滥用 symref 机制将 .git/HEAD 指向有趣的位置；它可能仍在这样做，如果是这种情况，我们应该扩展上面的列表以涵盖该用法。

回答by user611775

Normally, symrefs live under refs/— at least, this is what the git suite does (for example when using git filter-tree, you get refs/original/...). Some tools may choose to ignore refs that do not have the refs/prefix.

通常，symrefs 存在于refs/- 至少，这是 git 套件所做的（例如，当使用 git filter-tree 时，您会得到refs/original/...）。一些工具可能会选择忽略没有refs/前缀的引用。

$ git symbolic-ref refs/first refs/heads/master
$ git check-ref-format --print refs/first
refs/first

回答by user3622450

It would be desirable that symbolic links can be used more transparently and can be pushed as well. They could be a powerful tool for new workflows. Currently, if I create a symbolic link and then push is the server will have the hash not the link in the corresponding reference.

希望符号链接可以更透明地使用并且也可以推送。它们可以成为新工作流程的强大工具。目前，如果我创建一个符号链接然后推送是服务器将拥有哈希而不是相应引用中的链接。