Git符号引用的建议用法是什么? [英] What's the recommended usage of a Git symbolic reference?

查看:101
本文介绍了Git符号引用的建议用法是什么?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

以下shell代码正确地创建了一系列符号引用

  git symbolic-reffirstrefs / heads / master
git symbolic-refsecondfirst
git symbolic-refnested / thirdsecond
git symbolic-refrefs / heads / fourthnested /第三个

以下shell代码正确地解析了最新创建的符号引用,指向master的顶端。 / p>

  git show-refrefs / heads / fourth

在官方文档中没有描述这些用例( git-show-ref doc )。

然而,以下行不通

  git check-ref-format --printfirst

所以,我的问题是:


  • 可以在 refs / heads 目录?

  • 可以链接符号引用吗?

  • 由于check-ref-format失败当传递first时,这是否意味着不建议在与HEAD?或者,也许这个命令不是用来处理符号链接的?



我的目的是清楚地理解所支持的内容和我没有在任何地方工作,也没有从一个bug中受益。

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



Junio C Hamano ,领先git维护者(+8700提交)为我提供了以下答案。


现在只有两种有效类型的
symrefs :




  • .git / HEAD,指向refs / heads / hierarchy下的某处;


  • .git / refs / remotes / {某个远程名称} / HEAD,指向
    在refs / remotes / {相同远程
    名称} /层次结构中的某处。 / p>




代码可以准备解析
递归symrefs,除了
以外的其他两个symrefs在其他地方
指向的类型,但所有
都在
的设计范围之外,该机制旨在支持
。代码对它们做的
(没有崩溃)不是设计,
,而是一个未定义的行为。



这不会改变如果我们
决定重新组织1.8.0中的远程
跟踪层次结构,那么我们就会多。
前者根本不会改变,
后者将开始指向
refs / remotes / {相同的远程
名称} /头层次结构。



我隐约记得tg滥用symref
机制将.git / HEAD指向滑稽的
位置;它可能仍然是这样做的,
,如果是这种情况,我们应该
扩展上面的列表以涵盖
的使用。



The following shell code correctly creates a chain of symbolic references

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.

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

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/heads directory ?
  • 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 ?

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.

解决方案

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

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

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.

这篇关于Git符号引用的建议用法是什么?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆