Какое рекомендуемое использование символической ссылки Git?

Следующий код оболочки правильно создает цепочку символических ссылок

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"

И следующий код оболочки правильно решает последнюю созданную символическую ссылку на вершину мастера.

git show-ref "refs/heads/fourth"

Ни один из этих случаев использования не описан в официальной документации (git -symbolic-ref doc, git -show-ref doc).

Однако, не работает

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

Итак, мои вопросы:

  • Можно ли хранить символическую ссылку в каталоге refs/heads?
  • Можно ли закодировать символические ссылки?
  • Как сбой при обращении к методу check-ref-format при передаче "first", означает ли это, что не рекомендуется создавать символическую ссылку на том же уровне, что и "HEAD"? Или, может быть, эта команда не предназначена для обозначения символических ссылок?

Мое намерение состоит в том, чтобы получить четкое представление о том, что поддерживается, и что я ничем не работаю и не получаю от него ошибку.

Ответы

Ответ 1

Я в конце концов отправил этот вопрос в список рассылки git.

Junio ​​C Hamano, ведущий git сопровождающий (+8700 коммитов) предоставил мне следующие ответы.

Существует только два действительных вида symrefs прямо сейчас:

  • .git/HEAD, указывая где-то на ссылку refs/heads/hierarchy;

  • .git/refs/remotes/{какое-то удаленное имя}/HEAD, указывая где-нибудь под refs/remotes/{тот же пульт name}/hierarchy.

Код может быть готов к разрешению рекурсивные симрефы, симрефы, кроме вышеупомянутые два вида, symrefs, что точку в другом месте, но все они находятся вне сферы разработки какой механизм был предназначен для поддержка. Что делает код для них (без сбоев) - это не дизайн, а просто поведение undefined.

Это не изменится очень сильно, если мы принять решение о реорганизации удаленного иерархии отслеживания в 1.8.0. прежний не изменится вообще, и последний начнет указывать на refs/remotes/{тот же пульт name}/head.

Я смутно помню, как tg злоупотреблял symref механизм для пункта .git/HEAD при забавном местах; он все еще может это сделать, и если это так, мы должны распространите вышеуказанный список, чтобы использование.

Ответ 2

Как правило, symrefs живут под refs/ - по крайней мере, это то, что делает пакет git (например, при использовании дерева фильтров git вы получаете refs/original/...). Некоторые инструменты могут игнорировать ссылки, которые не имеют префикса refs/.

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

Ответ 3

Было бы желательно, чтобы символические ссылки могли использоваться более прозрачно и могут быть также нажаты. Они могут стать мощным инструментом для новых рабочих процессов. В настоящее время, если я создаю символическую ссылку и затем нажимаю, сервер будет иметь хэш не ссылку в соответствующей ссылке.