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

Question

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

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"? Или, может быть, эта команда не предназначена для работы с символическими ссылками?

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

Answer 1

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

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

На данный момент есть только два допустимых вида symref:

• .git/HEAD, указывающий куда-то в refs /глав / иерархия;

• .git / refs/remotes/{какое-то удаленное имя}/HEAD, указывающее куда-то под refs/remotes/{то же самое удаленное имя} / иерархия.

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

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

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

Answer 2

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

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

Answer 3

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