mikrocontroller.net

Forum: Compiler & IDEs Patch Datei mit GIT erzeugen


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Janvi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bin gerade am ausprobieren von GIT. Ich habe ein Repository gecloned, 
eine Änderung gemacht, die Datei mit add in die Stage übertragen und 
dann einen commit gemacht. Die Anzeige ist jetzt:

>git status
 On branch master
 Your branch is ahead of 'origin/master' by 1 commit.
 (use "git push" to publish your local commits)
nothing to commit, working tree clean
>

Wie kann ich hier eine patch Datei erzeugen ? Git diff erzeugt keine 
Ausgabe. Hätte ich das früher tun sollen ?

Autor: Hermann K. (r2d2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
git show HEAD

: Bearbeitet durch User
Autor: Janvi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ah, super - wär ich auch nie selbt draufgekommen. Es scheint in git 
mindestens soviel unendliche Tiefen wie in make zu geben.

Autor: Hermann K. (r2d2)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Git ist eigentlich recht logisch strukturiert, aber es ist halt einiges 
an Umgewöhnung wenn man von einem anderen System kommt.

Wenn es schon mehrere Commits sind kannst du auch "git diff $COMMITID$" 
wobei $COMMITID$ die ID des letzten Commits vor deinen Änderungen ist 
machen.

Idealerweise würdest du aber immer einen neuen Branch anlegen und kannst 
dann einfach "git diff master" machen um alle Änderungen in Bezug auf 
den master Branch anzuzeigen.

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ginge nicht auch einfach ein git diff origin/master?

Autor: Sven B. (scummos)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
git format-patch HEAD^..HEAD

Autor: super (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven B. schrieb:
> git format-patch HEAD^..HEAD

Danke, die erste richtige antwort.
Oder auch git format-patch HEAD~

(HEAD ist dabei der aktuellste lokale commit und ~ gibt an, diesen 
commit in format-patch inkludieren

Autor: super (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hermann K. schrieb:
> Idealerweise würdest du aber immer einen neuen Branch anlegen und kannst
> dann einfach "git diff master" machen um alle Änderungen in Bezug auf
> den master Branch anzuzeigen.

Diese Denkweise ist etwas arg von github geprägt.
Das ist nicht notwendig und hängt sehr stark von deinem use-case ab. 
Möchtest du einen github Pull-Request machen, dann muss man das so 
machen (mit ein paar Ausnahmen). Möchte man den patch an irgendeine 
Mailing-Liste schicken damit das aufgenommen wird, ist das nicht 
notwendig. Kommt halt ganz stark darauf an, was man genau machen will.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
super schrieb:
> Möchte man den patch an irgendeine
> Mailing-Liste schicken damit das aufgenommen wird, ist das nicht
> notwendig.

Es ist aber dennoch praktisch wenn sich deren master mittlerweile 
weiterbewegt hat. So kann man vorher noch seinen eigenen Branch wieder 
auf den aktuellen master rebasen oder den Master in seinen Branch 
reinmergen (denn man selbst kann seine eigenen Konflikte einfacher lösen 
als andere) und DANN erst den Patch erzeugen.

Wenn man alle denkbaren Zustände von sich und die von anderen immer 
sicher und wohlbehalten in separate Branches eingetütet hat so daß 
nichts verrutschen kann lebt und merged es sich viel entspannter. 
Branches kosten nichts und machen das Leben einfacher, also warum darauf 
verzichten?

: Bearbeitet durch User
Autor: Nikolaus S. (Firma: Golden Delicious Computers) (hns)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven B. schrieb:
> git format-patch HEAD^..HEAD

Genau. Einspielen kann man einen (oder mehrere) so erzeugte Patches mit

git am file.patch

: Bearbeitet durch User
Autor: Hermann K. (r2d2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rolf M. schrieb:
> Ginge nicht auch einfach ein git diff origin/master?

Ja, das ginge natürlich auch. Hab den Teil mit dem geclonten Repository 
überlesen.

Autor: Janvi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Möchtest du einen github Pull-Request machen ...

Ja, soweit bin ich zwischenzeitlich wobei das wohl als Nebenwirkung mit 
sich bringt, daß ich mit der hübschen patch Datei gar nix anfangen kann 
weil das auf Github dann sowieso automatisch geht.

Also, ich habe einen Fork auf den eigenen Usernamen in Github angelegt 
und diesen zur Durchführung der Änderungen auf die lokale Platte 
gecloned. Diese möchte ich am Master Branch machen denn an älteren 
weitergepflegten Versionen macht das keinen Sinn. Ich bin mir jetzt 
nicht sicher, warum ich auf dem eigenen Fork zur Änderung einen neuen 
Branch aufmachen soll. Vereinfacht das dem Projekteigentümer beim 
späteren Pull Request den Merge wenn jemand Anderes gleichzeitig 
ebenfalls etwas ändern will ?

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Janvi schrieb:
> warum ich auf dem eigenen Fork zur Änderung einen neuen
> Branch aufmachen soll

Nicht unbedingt. Aber wenn die anderen zwischenzeitlich auf deren master 
branch weiter arbeiten kannst Du Deinen master bei Dir ebenfalls 
problemlos nachziehen ohne deine eigenen Änderungen im Weg stehen zu 
haben.

Aber das ist eigentlich reine Geschmackssache und eine Frage dessen wie 
Du das organisieren willst, ob Du zum Beispiel an mehreren verschiedenen 
Änderungen arbeitest die Du unabhängig voneinander Pull-Requesten willst 
oder ob es nur diese eine einmalige Sache ist, ebensogut kannst Du auch 
Deinen Fork bereits als separaten Branch betrachten und damit genausogut 
einen Pull-Request machen.

Wenn Du etwas länger mit git arbeitest wird das bald alles leichter von 
der Hand gehen und das Jonglieren mit mehreren Branches so natürlich und 
unkompliziert erscheinen wie mal eben einen neuen Ordner anlegen um mal 
kurz was zwischenzuparken und nach ner halben Stunde wieder zu löschen.

: Bearbeitet durch User
Autor: DPA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Janvi schrieb:
> Ich bin mir jetzt nicht sicher, warum ich auf dem eigenen Fork zur
> Änderung einen neuen Branch aufmachen soll.

Auf GitHub werden bei einem pull request neue Kommits und sonstige 
Änderungen im Branch, der gemerged werden soll, automatisch in den pull 
request übernommen, solange der pull request noch offen ist. Das kann 
unpraktisch werden, wenn man den master branch genommen hat.

Autor: J. V. (janvi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie kann ich denn einen älteren Branch auf Github ansprechen ?
Mit dem Pulldown switch auf der Webseite wird die URL umgeschaltet,
aber

git clone https://github.com/user/projekt/tree/branch

meldet fatal: not found

während der master genommen wird wenn man tree/branch abschneidet.
Wenn ich das korrekt verstanden habe, sind alle branch in einem einzigen 
Repository enthalten, aber git branch meldet nur

* master

: Bearbeitet durch User
Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
git checkout BRANCHNAME

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
J. V. schrieb:
> aber git branch meldet nur
>
> * master

Was sagt "git branch -a"?

Autor: J. V. (janvi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C:\data\kcdev\kcd-i18n>git branch -a
* master
  remotes/origin/4.0
  remotes/origin/5.0
  remotes/origin/5.1
  remotes/origin/HEAD -> origin/master
  remotes/origin/master

C:\data\kcdev\kcd-i18n>git branch remotes/origin/5.1

C:\data\kcdev\kcd-i18n>git branch
* master
  remotes/origin/5.1

C:\data\kcdev\kcd-i18n>git checkout remotes/origin/5.1
warning: refname 'remotes/origin/5.1' is ambiguous.
Switched to branch 'remotes/origin/5.1'

C:\data\kcdev\kcd-i18n>git checkout 5.1
Switched to a new branch '5.1'
Branch '5.1' set up to track remote branch '5.1' from 'origin'.

C:\data\kcdev\kcd-i18n>git branch 5.1_bug463

C:\data\kcdv\kcd-i18n>git branch -a
* 5.1
  5.1_bug463
  master
  remotes/origin/5.1
  remotes/origin/4.0
  remotes/origin/5.0
  remotes/origin/5.1
  remotes/origin/HEAD -> origin/master
  remotes/origin/master

C:\data\kcdev\kcd-i18n>git checkout 5.1_bug463
Switched to branch '5.1_bug463'

C:\data\kcdev\kcd-i18n>git branch -a
  5.1
* 5.1_bug463
  master
  remotes/origin/5.1
  remotes/origin/4.0
  remotes/origin/5.0
  remotes/origin/5.1
  remotes/origin/HEAD -> origin/master
  remotes/origin/master

: Bearbeitet durch User
Autor: Sven B. (scummos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist bisschen verwirrend aber was du tust ist Unsinn.

Die branches mit dem remotes/-Präfix sind nicht auf deinem Rechner, die 
sind nur auf den Remotes. Was du eigentlich willst, ist einen lokalen 
Branch anlegen, der den entsprechenden remote-Branch trackt.

Das geht z.B. für remotes/origin/5.0 normalerweise mit
git branch 5.0
git remote --set-upstream-to remotes/origin/5.0

aber da das so umständlich ist, tut
git checkout 5.0

dasselbe, wenn der lokale Branch "5.0" nicht existiert.

Autor: J. V. (janvi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe jetzt mit checkout 5.1 auf dem lokalen rep gearbeitet
und es funktioniert soweit alles.
Danach add. auf die Stage und commit, dann push und es kommt der Browser 
und will die Zugangsdaten zu github wissen. Das Ergebniss sollte jetzt 
auf meinem Branch sichbar sein was es aber nicht ist.
Wie funkioniert das jetzt noch bis zu einem Pull request damit es ins 
eigentliche Projekt einfliesst ? Im github http werden upload und pull 
request angeboten. Sollte ich diese nur für das geänderte File benutzen 
?

: Bearbeitet durch User

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.