Может ли ссылка, хранящаяся вне ссылок / заголовков, считаться веткой, проверенной и обработанной как нормальная ветка?

Question

Теперь я не знаю, считается ли ссылка ветвью, только если она находится внутри ссылок / заголовков, и на самом деле вопрос был ранее озаглавлен. Как оформить ветку, хранящуюся вне ссылок / заголовков ?, Так что я не уверен, могут ли ссылки, хранящиеся вне ссылок / заголовков, все еще называться "правильными ветвями" или нет, но дело в том:

Допустим, у меня есть ссылка на коммит, как и все обычные ветки, но хранящиеся вне ссылок / заголовков; например, примечания, добавленные с помощью git-notes, хранятся таким образом, по умолчанию в ref refs/ notes / commits.

Может ли он все-таки каким-то образом быть извлечен, как если бы это была нормальная ветвь (без выполнения проверки с отсоединенной головкой), а затем обработаться другими командами git (rebase, cherry-pick и т. Д.), как если бы это была нормальная ветка refs/глав?

Я знаю что нормальный git checkout будет только проверять его как коммит, переводя хранилище в отдельное состояние.

Я нашел способ, который, кажется, работает, а именно:

git symbolic-ref HEAD refs/MyUnusualRefPath/MyUnusualRef
git checkout -f HEAD

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

Я попытался посмотреть на источник для git checkout, но через некоторое время стало ясно, что мне лучше опубликовать вопрос в переполнении стека (я искал в Интернете раньше, конечно).
Оглядываясь назад, можно было бы потратить меньше времени на изучение (всего) исходного кода git.

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

Answer 1

Правильная ветвь (то есть не отсоединенный HEAD) - это коммит, сохраненный в refname, на который непосредственно ссылается HEAD.
Это означает, что HEAD является символическим ref для refname (который, в свою очередь, содержит фактический коммит). Смотрите также " HEAD: текущий коммит "

Поэтому git symbolic-ref HEAD refs/MyUnusualRefPath/MyUnusualRef работает здесь.

Вы можете хранить эту ссылку в любом месте refs/, но:

• как упоминалось в " Git: refname" master 'является неоднозначным ', git будет искать этот реф только в нескольких выбранных местах в refs/,
• перечисление ветвей может не включать этот реф.
  Смотрите commit aedcb7d (для предстоящего git 2.7)

Также по умолчанию мы сортируем по 'refname'.
Поскольку 'HEAD' находится в алфавитном порядке перед 'refs/...', мы получаем массив, состоящий из 'HEAD' ref, затем локальных ветвей и, наконец, ветвей удаленного отслеживания.

Новый branch.c Кажется, что код фильтруется только в refs/heads/... а также refs/remotes/...

---

Примечание: только Git 2.11+ будет обнаруживать и сопротивляться символической ссылке с GIT_DIR/refs, которая сделает цикл разрешения имен навсегда.

Смотрите коммит e8c42cb, коммит 3f7bd76 (06 октября 2016 г.) Джеффа Кинга ( peff )
^{(Объединено Юнио С Хамано -} gitster ^{- в коммите f7300cb, 17 октября 2016 г.)}