Как устанавливается origin / HEAD?

Question

Как устанавливается origin / HEAD?

у меня есть ветка, настроенная для отслеживания ссылки в origin. git checkout <branchname> переключается на эту ветку, и A git status покажет мне, как далеко впереди или позади моей ветви от происхождения, но я удивлен, что origin/HEAD по-прежнему указывает на origin/master, а не origin/<branchname>

Итак, мой вопрос в том, при каких обстоятельствах origin/HEAD перемещается?

EDIT:

Я ценю ответы о как чтобы переместить начало / голову, но меня интересует, что" органически " движется это, вне меня явно говорит ему сделать это.

например, когда я переключаю ветви, git делает головную точку на ветке, которую я проверяю, поэтому я удивлен, что origin/HEAD не перемещается таким же образом.

647 5

git

5 ответов:

Comments

Ничего не найдено.

Cascabel · Accepted Answer · 2017-05-23 13:31:12

обратите внимание, что ваш вопрос показывает немного непонимания. origin / HEAD представляет ветвь по умолчанию на пульте дистанционного управления, то есть голова, которая находится в том удаленном репозитории, который вы вызываете origin. Когда вы переключаете ветви в своем РЕПО, вы не влияете на это. То же самое верно для удаленных филиалов; вы могли бы master и origin/master в вашем РЕПО, где origin/master представляет собой локальную копию master ветвь в удаленном репозитории.

голова origin изменится только в том случае, если вы или кто-то другой действительно изменит ее в удаленном репозитории, что в принципе никогда не должно происходить - вы хотите, чтобы ветвь по умолчанию публичного РЕПО оставалась постоянной, на стабильной ветви (вероятно, master). origin / HEAD-это локальная ссылка, представляющая локальную копию HEAD в удаленном репозитории. (его полное имя refs / remotes / origin / HEAD.)

Я думаю, что выше ответы, что вы на самом деле хотел бы знать, но идти вперед и ответить на вопрос, который вы явно задали... origin / HEAD устанавливается автоматически при клонировании репозитория, и это все. Странно, что это не набор команд git remote update - Я считаю, что единственный способ изменить это, если вы вручную измените его. (Под изменением я имею в виду точку на другую ветвь; очевидно, фиксация указывает на изменения, если эта ветвь изменяется, что может произойти при fetch / pull / remote обновление.)

Edit: проблема, обсуждаемая ниже, была исправлена в Git 1.8.4.3; см. обновление.

однако есть небольшая оговорка. HEAD-это символический ref, указывающий на ветвь, а не непосредственно на фиксацию, но протоколы удаленной передачи git только сообщают о фиксации для refs. Таким образом, Git знает SHA1 фиксации, на которую указывает HEAD и все другие ссылки; затем он должен вывести значение HEAD by поиск ветви, которая указывает на ту же фиксацию. Это означает, что если две ветви случайно указывают туда, это неоднозначно. (Я считаю, что он выбирает мастера, если это возможно, а затем возвращается к первому алфавиту.) Вы увидите, что это сообщается в выходных данных git remote show origin:
$ git remote show origin
* remote origin
  Fetch URL: ...
  Push  URL: ...
  HEAD branch (remote HEAD is ambiguous, may be one of the following):
    foo
    master
как ни странно, хотя понятие HEAD, напечатанное таким образом, изменится, если что-то изменится на пульте дистанционного управления (например, если foo будет удален), оно на самом деле не обновляется refs/remotes/origin/HEAD. Это может привести к очень странным ситуациям. Скажите, что в выше пример origin / HEAD фактически указал на foo, и ветвь Foo origin была затем удалена. Тогда мы можем сделать следующее:
$ git remote show origin
...
HEAD branch: master
$ git symbolic-ref refs/remotes/origin/HEAD
refs/remotes/origin/foo
$ git remote update --prune origin
Fetching origin
 x [deleted]         (none)     -> origin/foo
   (refs/remotes/origin/HEAD has become dangling)
поэтому, хотя удаленное шоу знает, что HEAD является мастером, он ничего не обновляет. Несвежая ветка foo правильно обрезается, и голова становится болтающейся (указывая на несуществующую ветку), и это еще не обновляет его, чтобы указать на master. Если вы хотите исправить это, используйте git remote set-head origin -a, которое автоматически определяет голову начала как выше, и после этого фактически устанавливает origin / HEAD для указания на соответствующую удаленную ветвь.

eis · Accepted Answer · 2017-05-23 15:18:14

это ваша настройка в качестве владельца вашего локального РЕПО. Измените его следующим образом:
git remote set-head origin some_branch
и origin / HEAD будет указывать на вашу ветку вместо master. Это будет применяться только к вашему РЕПО, а не для других. По умолчанию он будет указывать на master, если что-то еще не было настроено на удаленном РЕПО.

ручной ввод для удаленного set-head обеспечивает некоторую хорошую информацию об этом.

Edit: чтобы подчеркнуть: без вашего ведома чтобы, единственный способ, которым он будет "двигаться", был бы такой случай, как переименовать ветку master, который я не думаю, что считается "органическим". Так что, я бы сказал, органично она не двигается.

Robert Siemer · Accepted Answer · 2017-03-22 18:23:50

что двигает начало / голову "органически"?

git clone устанавливает его один раз в том месте, где голова находится на начало координат

он служит в качестве ветви по умолчанию для проверки после клонирования с git clone

что означает HEAD on origin?

на голых репозиториях (часто репозитории "на серверах") он служит маркером для ветки по умолчанию, потому что git clone использует таким образом

в не-голых репозиториях (локальных или удаленных) он отражает текущую проверку репозитория

что устанавливает начало / голову?

git clone загружает и устанавливает его в

это имело бы смысл, если git fetch обновляет его, как и любую другую ссылку, но это не

git remote set-head origin -a загружает и устанавливает его

полезно обновить локальные знания о том, что удаленный считает " по умолчанию филиал"

Тривиа

origin/HEAD также можно установить любое другое значение, не связываясь с пультом дистанционного управления:git remote set-head origin <branch>

Я не вижу никакого прецедента для этого, кроме тестирования

к сожалению, ничто не может установить голову на пульте дистанционного управления

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

Pablo Maurin · Accepted Answer · 2012-01-12 21:32:55

помните, что есть два независимые репозитории Git, о которых мы говорим. Ваше локальное РЕПО с вашим кодом и удаленным запуском где-то еще.

вы правы, когда вы меняете ветку, голова указывает на вашу текущую ветку. Все это происходит на вашем локальном репозитории Git. Не удаленное РЕПО, которое может принадлежать другому разработчику, или расположенное на сервере в вашем офисе, или github, или другой каталог в файловой системе, или т. д...

ваш компьютер (локальное РЕПО)не имеет права изменять указатель головы на удаленном РЕПО git. Например, он может принадлежать другому разработчику.

еще одна вещь, которую ваш компьютер называет origin/XXX-это понимание вашего компьютера состояния пульта дистанционного управления во время последней выборки.

Итак, что бы "органически" обновить origin / HEAD? Это будет активность на удаленном репозитории git. Не ваше местное РЕПО.

люди упомянули

git symbolic-ref HEAD refs / head/my_other_branch

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

jubobs · Accepted Answer · 2017-05-23 15:02:51

отказ от ответственности: это обновление для Jefromi это, который я пишу, чтобы сэкономить любопытным некоторое время.

Я тщетно пытался повторить (в Git 2.0.1) в remote HEAD is ambiguous сообщение о том, что Jefromi упоминает в своем ответе, поэтому я сделал немного копать (путем клонирования https://github.com/git/git и поиск в журнале). Раньше было так
Determining HEAD is ambiguous since it is done by comparing SHA1s.

In the case of multiple matches we return refs/heads/master if it
matches, else we return the first match we encounter. builtin-remote
needs all matches returned to it, so add a flag for it to request such.
(Commit 4229f1fa325870d6b24fe2a4c7d2ed5f14c6f771, датированный 27 февраля 2009 г., найдено с git log --reverse --grep="HEAD is ambiguous")
, С тех пор эта двусмысленность была снята:
One long-standing flaw in the pack transfer protocol used by "git
clone" was that there was no way to tell the other end which branch
"HEAD" points at, and the receiving end needed to guess.  A new
capability has been defined in the pack protocol to convey this
information so that cloning from a repository with more than one
branches pointing at the same commit where the HEAD is at now
reliably sets the initial branch in the resulting repository.
(Commit 9196a2f8bd46d36a285bdfa03b4540ed3f01f671, датированный 8 ноября 2013 года, найдено с git log --grep="ambiguous" --grep="HEAD" --all-match)

Edit (спасибо торек):
$ git name-rev --name-only 9196a2f8bd46d36a285bdfa03b4540ed3f01f671
tags/v1.8.4.3~3
это означает, что если вы используете Git v1.8.4. 3 или более поздней версии, вы не должны столкнуться с какой-либо неоднозначной проблемой удаленной головы.