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

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

20 голосов
/ 13 февраля 2011

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

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?
  • Можно ли связывать символические ссылки?
  • Поскольку проверка-ref-format завершается неудачно при передаче "first", означает ли это, что не рекомендуется создавать символическую ссылку на том же уровне, что и "HEAD"? Или, может быть, эта команда не предназначена для работы с символическими ссылками?

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

Ответы [ 3 ]

16 голосов
/ 15 февраля 2011

Я в конечном итоге отправил этот вопрос в список рассылки git development.

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

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

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

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

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

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

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

3 голосов
/ 13 февраля 2011

Обычно 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
1 голос
/ 10 мая 2014

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

...