Verständnisfrage zu git

franc

Christoph schrieb:

Mach mal git branch -a, um zu sehen welche branches du überhaupt hast. ...

c:\apache\Apache2\htdocs\kimai-git>git branch -a
  fcw
  master
  origin
* upstream
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
  remotes/upstream/master

Mir scheint das ist schon völlig verkorkt

franc

So also den branch upstream, der ja nur für Verwirrung sorgt, habe ich wieder gelöscht, so schaut das jetzt aus:

c:\apache\Apache2\htdocs\kimai-git>git checkout fcw
Switched to branch 'fcw'

c:\apache\Apache2\htdocs\kimai-git>git branch -d upstream
Deleted branch upstream (was 119cc7f).

c:\apache\Apache2\htdocs\kimai-git>git checkout master
Switched to branch 'master'
Your branch is behind 'origin/master' by 1 commit, and can be fast-forwarded.

c:\apache\Apache2\htdocs\kimai-git>git checkout origin/master
Note: checking out 'origin/master'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b new_branch_name

HEAD is now at d53d059... Ignore some new files

c:\apache\Apache2\htdocs\kimai-git>git branch -a
* (no branch)
  fcw
  master
  origin
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
  remotes/upstream/master

So langsam funktioniert das auch mit dem git checkout ...

Ich bin mir nicht sicher, ob ich meine Änderungen in meinen Fork korrekt auf github gepusht habe, sonst würde ich nämlich jetzt wirklich alles nochmal löschen und neu pullen.
Warum steht bei mir denn da untereinander master UND origin? Ist das nicht das gleiche und beides lokal?

Christoph

franc schrieb:

Christoph schrieb:

Mach mal git branch -a, um zu sehen welche branches du überhaupt hast. ...
c:\apache\Apache2\htdocs\kimai-git>git branch -a
  fcw
  master
  origin
* upstream
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
  remotes/upstream/master
Mir scheint das ist schon völlig verkorkt

Ja, deswegen mein Tipp ein neues git clone zu machen von deinem (deinem persönlichen) github-Repository (nicht das Original-Repository).

Wenn du das nicht möchtest, würde ich erstmal master auschecken und dann die beiden Branches "origin" und "upstream" löschen mit git branch -d. Dann master mit --set-upstream wieder reparieren, sodass er origin/master trackt. Dann das machen, was ich in meinem ersten Posting hier beschrieben habe.

Aber nochmal, was spricht gegen die Anleitung von github?
$ git fetch upstream
$ git merge upstream/master

Dann musst du den Original-Branch gar nicht auschecken, sondern bekommst die Änderungen in deinen Branch gemerged. Du siehst dann auch exakt die Änderungen, die du gemacht hast gegenüber den Änderungen, die upstream passiert sind. Diese Änderungen sind ja normalerweise das interessante, nicht der tatsächliche Zustand des upstream-Repositories. Man möchte ja nicht tausende Zeilen manuell vergleichen, da ist es gut, wenn git einem ein diff automatisch erstellt und man nicht manuell zwischen Original-Branch und eigenem Branch hin- und herwechseln muss, um zu vergleichen.

Christoph

franc schrieb:

Ich bin mir nicht sicher, ob ich meine Änderungen in meinen Fork korrekt auf github gepusht habe, sonst würde ich nämlich jetzt wirklich alles nochmal löschen und neu pullen.
Warum steht bei mir denn da untereinander master UND origin? Ist das nicht das gleiche und beides lokal?

Du hast scheinbar manuell einen Branch namens "origin" angelegt.

Die Namen "master", "origin", und so weiter haben für git keinerlei besondere Bedeutung. Das sind keine keywords und die werden von git auch nicht speziell behandelt. Das sind einfach nur willkürliche Namen für einen Branch oder ein remote repository. Du kannst also ein remote repository "origin" nennen, du kannst aber genausogut einen Branch "origin" nennen. Das eine hat mit dem anderen nichts zu tun.

franc

Ah, danke, langsam wird es sehr viel klarer.
Ich glaube ich habe aber auch im GitHub Mist gebaut, dort habe ich zwei Mal gepusht, einmal in HEAD, einmal in master, das sieht jetzt so aus:

http://img1.uploadscreenshot.com/images/orig/3/9008122558-orig.jpg

und:

http://img1.uploadscreenshot.com/images/orig/3/9008193320-orig.jpg

Habe ich jetzt im GitHub zwei branches, einen HEAD einen master?
Beide Namen auch wieder willkürlich und ohne Sonderbedeutung?

Die Lösung mit dem

$ git fetch upstream
$ git merge upstream/master

werde ich wählen, aber ich muss erst mal einen sauberen Zustand im GitHub erhalten, bevor mich die Verwirrung völlig vernebelt.

EDIT: ich muss dazusagen, dass ich beim pushen zu GitHub TortoiseGit verwendet hatte und nicht genau wusste was ich tat.
Kann es sein, dass ich dabei einen branch "HEAD" angelegt habe, also dass dieses "HEAD" gar keine Sonderbedeutung hat (s.o.)?

Christoph

franc schrieb:

http://img1.uploadscreenshot.com/images/orig/3/9008122558-orig.jpg

und:

http://img1.uploadscreenshot.com/images/orig/3/9008193320-orig.jpg

Nimm doch bitte png für Screenshots, dann wird die Datei kleiner und das Bild nicht so unscharf.

franc schrieb:

Kann es sein, dass ich dabei einen branch "HEAD" angelegt habe, also dass dieses "HEAD" gar keine Sonderbedeutung hat (s.o.)?

Ja, genau danach sieht es aus. Wenn du sicher bist, dass dieser Branch gelöscht werden kann, kannst du ihn von github löschen mit
$ git push dein_github_repo :HEAD

Der Doppelpunkt vor HEAD ist wichtig.

HEAD hat zwar in git eine Sonderbedeutung, denn es zeigt auf den aktuell ausgecheckten commit. Allerdings hält git den Nutzer nicht davon ab, einen Branch namens "HEAD" anzulegen.

franc

Christoph schrieb:

...Nimm doch bitte png für Screenshots, dann wird die Datei kleiner und das Bild nicht so unscharf. :)...

Da habe ich gar keinen Einfluss darauf, das ist dieser Dienst uploadscreenshot.com, der erstellt das aus der Zwischenablage selbst.

Christoph schrieb:

...HEAD hat zwar in git eine Sonderbedeutung, denn es zeigt auf den aktuell ausgecheckten commit. Allerdings hält git den Nutzer nicht davon ab, einen Branch namens "HEAD" anzulegen.

Ja, das hat geklappt!
Anscheinend habe ich mit TortoiseGit einen branch namens HEAD erstellt, den ich jetzt erfolgreich gelöscht habe.
Langsam lichtet sich der Nebel, die Sonne geht auf

Ich habe gemacht:

git push origin :HEAD

Jetzt lösche ich lokal alles und mach einen neuen pull.

Christoph

franc schrieb:

Christoph schrieb:

...Nimm doch bitte png für Screenshots, dann wird die Datei kleiner und das Bild nicht so unscharf. :)...

Da habe ich gar keinen Einfluss darauf, das ist dieser Dienst uploadscreenshot.com, der erstellt das aus der Zwischenablage selbst.

Dann würde ich einen Dienst nehmen, jpeg für Screenshot ist wirklich nicht nett gegenüber dem, der es anschauen soll.

franc schrieb:

Christoph schrieb:

...HEAD hat zwar in git eine Sonderbedeutung, denn es zeigt auf den aktuell ausgecheckten commit. Allerdings hält git den Nutzer nicht davon ab, einen Branch namens "HEAD" anzulegen.

Ja, das hat geklappt!
Anscheinend habe ich mit TortoiseGit einen branch namens HEAD erstellt, den ich jetzt erfolgreich gelöscht habe.
Langsam lichtet sich der Nebel, die Sonne geht auf

Sehr schön. Es ist bei git zum Glück ziemlich schwer, wirklich Daten zu verlieren, solange sie irgendwann mal committet wurden.

franc

Christoph schrieb:

...jpeg für Screenshot ist wirklich nicht nett gegenüber dem, der es anschauen soll...

Ich kann da gar keine Unschärfe erkennen, die Bilder sind doch einwandfrei scharf!?

Christoph schrieb:

...Sehr schön. Es ist bei git zum Glück ziemlich schwer, wirklich Daten zu verlieren, solange sie irgendwann mal committet wurden.

Das beruhigt mich
Natürlich habe ich aber dennoch vor dem Löschen des lokalen Repositorys gesichert
Jetzt habe ich auch, deinem Rad folgend, mit dem remote Original gemerged mit:

git merge upstream/master

Da musste ich ein paar Dateien händisch korrigieren, aber dann ging es und ich habe jetzt in meinem lokalen und remote Repository einen Zustand mit meinen Änderungen und denen vom Original.
Das war ein wichtiger Tipp, glaube ich.
Das hätte ich nämlich nicht gemacht und mich immer weiter vom Original entfernt, bis es kaum mehr zu mergen gewesen wäre, fürchte ich.
Je nach dem natürlich nur, wie eifrig die Original-Entwickler überhaupt ändern

Es ist für mich noch leicht verwirrend, dass es mehrere Zustände gibt, lokal, remote, remote upstream usw.

Ich habe auch gesehen, was ich bei TortoiseGit falsch gemacht habe:

http://www.abload.de/img/head80ko8.png

Ich hatte hier HEAD ausgewählt und damit wohl einen neuen branch erstellt.
Komisch dass das so geht.

Christoph

franc schrieb:

Ich hatte hier HEAD ausgewählt und damit wohl einen neuen branch erstellt.
Komisch dass das so geht.

Das funktioniert, weil ein Branch lokal und remote nicht denselben Namen haben muss. Du kannst zum Beispiel
$ git push origin master:foo
ausführen. Dann wird der Branch "master" im lokalen Repository auf den Branch "foo" gepusht im Repository namens "origin". Wenn der Branch "foo" im Repository "origin" nicht existiert, wird er angelegt.

Was tortoisegit gemacht hat, war also vermutlich
$ git push origin master:HEAD