Может ли ссылка, хранящаяся вне ссылок / заголовков, считаться веткой, проверенной и обработанной как нормальная ветка?
Теперь я не знаю, считается ли ссылка ветвью, только если она находится внутри ссылок / заголовков, и на самом деле вопрос был ранее озаглавлен. Как оформить ветку, хранящуюся вне ссылок / заголовков ?, Так что я не уверен, могут ли ссылки, хранящиеся вне ссылок / заголовков, все еще называться "правильными ветвями" или нет, но дело в том:
Допустим, у меня есть ссылка на коммит, как и все обычные ветки, но хранящиеся вне ссылок / заголовков; например, примечания, добавленные с помощью 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.
Я действительно нуждался в этом, чтобы решить проблемы с обменом (ужасно реализованными / задокументированными) заметками между репозиториями, но, пожалуйста, не сосредотачивайтесь на этом и просто отвечайте на мой вышеупомянутый вопрос, или просто игнорируйте это и позволяйте другим, кто осведомлен о это ответ.
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 г.)