Wie wird origin/HEAD gesetzt?

Ich habe eine Verzweigung eingerichtet, um eine Referenz im Ursprung zu verfolgen. git checkout <branchname> wechselt zu diesem Zweig, und a git status wird mir zeigen, wie weit vorn oder hinten mein Zweig vom Ursprung her ist, aber das wundert mich origin/HEAD weist noch darauf hin origin/masterund nicht origin/<branchname>

Meine Frage ist also, unter welchen Umständen wird Origin/HEAD verschoben?

BEARBEITEN:

Ich schätze die Antworten über wie Ursprung/HEAD zu bewegen, aber ich interessiere mich dafür, was es “organisch” bewegt, außer dass ich es ausdrücklich dazu auffordere.

Wenn ich zum Beispiel Branches wechsle, lässt git HEAD auf den Branch zeigen, den ich auschecke, also bin ich überrascht, dass sich origin/HEAD nicht auf die gleiche Weise bewegt.

Beachten Sie zunächst, dass Ihre Frage ein wenig missverstanden wird. origin/HEAD repräsentiert den Standardzweig auf der Fernbedienung, dh der HEAD, der sich in dem entfernten Repository befindet, das Sie origin nennen. Wenn Sie Branches in Ihrem Repo wechseln, haben Sie darauf keinen Einfluss. Dasselbe gilt für Remote-Zweige; Vielleicht hast du master und origin/master in Ihrem Repo, wo origin/master stellt eine lokale Kopie der dar master Verzweigung im entfernten Repository.

Der HEAD von origin wird sich nur ändern, wenn Sie oder jemand anderes ihn tatsächlich im Remote-Repository ändertwas im Grunde nie passieren sollte – Sie möchten, dass der Standardzweig ein öffentliches Repo auf dem stabilen Zweig (wahrscheinlich Master) konstant bleibt. origin/HEAD ist eine lokale Referenz, die eine lokale Kopie des HEAD im entfernten Repository darstellt. (Der vollständige Name lautet refs/remotes/origin/HEAD.)

Ich denke, das Obige beantwortet, was Sie eigentlich wissen wollten, aber um die Frage zu beantworten, die Sie explizit gestellt haben … origin/HEAD wird automatisch gesetzt, wenn Sie ein Repository klonen, und das war es auch schon. Seltsamerweise ist es das nicht gesetzt durch Befehle wie git remote update – Ich glaube, der einzige Weg, wie es sich ändern wird, ist, wenn Sie es manuell ändern. (Mit Änderung meine ich auf einen anderen Zweig verweisen; offensichtlich zeigt der Commit auf Änderungen, wenn sich dieser Zweig ändert, was beim Abrufen/Pullen/Remote-Update passieren kann.)

Bearbeiten: Das unten beschriebene Problem wurde in behoben Git 1.8.4.3; siehe diese Aktualisierung.

Es gibt jedoch eine kleine Einschränkung. HEAD ist eine symbolische Referenz, die auf einen Zweig statt direkt auf einen Commit zeigt, aber die Git-Remote-Transfer-Protokolle melden nur Commits für Refs. Git kennt also den SHA1 des Commits, auf den HEAD und alle anderen Refs zeigen; es muss dann den Wert von HEAD ableiten, indem es einen Zweig findet, der auf denselben Commit zeigt. Das bedeutet, wenn zwei Zweige zufällig dorthin zeigen, ist es mehrdeutig. (Ich glaube, es wählt nach Möglichkeit den Master aus und fällt dann alphabetisch auf den ersten zurück.) Sie werden dies in der Ausgabe von sehen 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

Obwohl sich der auf diese Weise gedruckte Begriff von HEAD ändert, wenn sich Dinge auf der Fernbedienung ändern (z. B. wenn foo entfernt wird), wird er seltsamerweise nicht wirklich aktualisiert refs/remotes/origin/HEAD. Das kann zu wirklich merkwürdigen Situationen führen. Angenommen, im obigen Beispiel zeigte origin/HEAD tatsächlich auf foo, und der foo-Zweig von origin wurde dann entfernt. Das können wir dann machen:

$ 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)

Obwohl Remote Show also weiß, dass HEAD Master ist, aktualisiert es nichts. Der veraltete foo-Zweig wird korrekt beschnitten, und HEAD wird baumelnd (zeigt auf einen nicht vorhandenen Zweig) und es still aktualisiert es nicht so, dass es auf den Master zeigt. Wenn Sie dies beheben möchten, verwenden Sie git remote set-head origin -adas wie oben automatisch den HEAD von origin bestimmt und dann origin/HEAD tatsächlich so einstellt, dass es auf den entsprechenden Remote-Zweig zeigt.

Dies ist Ihre Einstellung als Eigentümer Ihres lokalen Repos. Ändern Sie es so:

git remote set-head origin some_branch

Und origin/HEAD zeigt auf Ihren Branch statt auf master. Dies würde dann nur für Ihr Repo gelten und nicht für andere. Standardmäßig zeigt es auf master, es sei denn, es wurde etwas anderes auf dem Remote-Repo konfiguriert.

Manuelle Eingabe für Remote Set-Head liefert einige gute Informationen dazu.

Bearbeiten: Um zu betonen: Ohne dass Sie es sagen, wäre der einzige Weg, wie es “bewegt” würde, ein Fall wie das Umbenennen des Master-Zweigs, der meiner Meinung nach nicht als “organisch” gilt. Ich würde also sagen, dass es sich organisch nicht bewegt.

Was bewegt origin/HEAD „organisch“?

• git clone setzt es einmal auf die Stelle, an der HEAD auf Ursprung steht
  • Er dient als Standard-Zweig zum Auschecken nach dem Klonen git clone

Was bedeutet HEAD on origin?

• Auf Bare Repositories (häufig Repositories „auf Servern“) dient es als Markierung für den Default-Zweig, weil git clone nutzt es so
• Bei nicht-nackten Repositorys (lokal oder remote) spiegelt es den aktuellen Checkout des Repositorys wider

Was setzt origin/HEAD?

• git clone holt und setzt es
• es wäre sinnvoll, wenn git fetch aktualisiert es wie jede andere Referenz, tut es aber nicht
• git remote set-head origin -a holt und setzt es
  • nützlich, um das lokale Wissen darüber zu aktualisieren, was Remote als „Standard-Zweig“ betrachtet

Kleinigkeiten

• origin/HEAD kann auch auf jeden anderen Wert eingestellt werden, ohne die Fernbedienung zu kontaktieren: git remote set-head origin <branch>
  • Ich sehe dafür keinen Anwendungsfall, außer zum Testen
• leider ist nichts in der Lage, HEAD auf der Fernbedienung einzustellen
• ältere Git-Versionen wussten nicht, auf welchen Branch HEAD auf der Remote zeigt, sondern nur, welchen Commit-Hash er schließlich hat: also hat er hoffentlich einfach einen Branch-Namen ausgewählt, der auf denselben Hash zeigt

Haftungsausschluss: Dies ist ein Update zu Cascabels Antwort, die ich schreibe, um den Neugierigen etwas Zeit zu sparen.

Ich habe vergeblich versucht, (in Git 2.0.1) das zu replizieren remote HEAD is ambiguous Nachricht, die Cascabel in seiner Antwort erwähnt; Also habe ich ein bisschen gegraben (durch Klonen https://github.com/git/git und Durchsuchen des Protokolls). Früher war das so

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.

(Begehen 4229f1fa325870d6b24fe2a4c7d2ed5f14c6f771datiert 27.02.2009, gefunden bei git log --reverse --grep="HEAD is ambiguous")

Aber, die fragliche Unklarheit wurde inzwischen aufgehoben:

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.

(Begehen 9196a2f8bd46d36a285bdfa03b4540ed3f01f671datiert 08.11.2013, gefunden bei git log --grep="ambiguous" --grep="HEAD" --all-match)

Bearbeiten (dank torek):

$ git name-rev --name-only 9196a2f8bd46d36a285bdfa03b4540ed3f01f671
tags/v1.8.4.3~3

Dies bedeutet, dass, wenn Sie verwenden Git v1.8.4.3 oder höhersollten Sie auf kein mehrdeutiges Remote-HEAD-Problem stoßen.

Denken Sie daran, es gibt zwei unabhängige Git-Repos, über die wir sprechen. Ihr lokales Repo mit Ihrem Code und die Fernbedienung, die woanders läuft.

Sie haben Recht, wenn Sie einen Zweig ändern, zeigt HEAD auf Ihren aktuellen Zweig. All dies geschieht in Ihrem lokalen Git-Repo. Nicht das Remote-Repo, das einem anderen Entwickler gehören könnte, oder auf einem Server in Ihrem Büro oder Github oder einem anderen Verzeichnis im Dateisystem oder etc …

Ihr Computer (lokales Repo) hat nichts damit zu tun, den HEAD-Zeiger auf dem Remote-Git-Repo zu ändern. Es könnte beispielsweise einem anderen Entwickler gehören.

Eine weitere Sache, was Ihr Computer Origin/XXX nennt, ist das Verständnis Ihres Computers vom Status der Fernbedienung zum Zeitpunkt des letzten Abrufs.

Was würde also origin/HEAD “organisch” aktualisieren? Es wäre eine Aktivität auf dem Remote-Git-Repo. Nicht Ihr lokales Repo.

Leute haben erwähnt

git symbolic-ref HEAD refs/head/my_other_branch

Normalerweise wird dies verwendet, wenn auf einem Server ein gemeinsam genutztes zentrales Git-Repository zur Verwendung durch das Entwicklungsteam vorhanden ist. Es wäre ein Befehl, der auf dem Remote-Computer ausgeführt wird. Sie würden dies als Aktivität im Remote-Git-Repo sehen.

Führen Sie die folgenden Befehle über die Git-CLI aus:

# move to the wanted commit
git reset --hard <commit-hash> 

# update remote
git push --force origin <branch-name> 

Es wird von eingestellt git clone und auch durch git remote add -m master $url. Ansonsten müsstest du es manuell einstellen.

Ich habe einige Patches geschickt, um aktualisiert zu werden git fetch sowie (je nach Konfiguration). Das wäre meiner Meinung nach der organischste Weg, es zu aktualisieren. Leider wurden sie noch nicht zusammengeführt.