-
Notifications
You must be signed in to change notification settings - Fork 2
6_Änderungen von PK Repo ins linked.swissbib Repo übernehmen
!!! Diese Seite wurde als Hilfsseite während der Entwicklung erstellt und enthält gegebenfalls veraltete Angaben! !!!
Diese Seite beschreibt, wie wir Änderungen vom PK-Repo in dieses Repo übernehmen können. Allgemein gesprochen möchten wir ein cherry-pick auf ein remote repository durchführen. Annahme ist, dass wir auf der virtuellen Maschine arbeiten, welche wir auch den Studenten zur Verfügung gestellt haben.
Die Anleitung ist unterteilt in zwei Schritte:
- Einmalige Einrichtung: Diese müssen nur einmal pro VM durchgeführt werden.
- Sich wiederholende Schritte: Diese müssen für jede Änderung, welche übernommen werden soll, wiederholt werden.
Auf der virtuellen Maschine wird ein neues sog. remote mit dem Namen lsb (zusätzlich zum bestehenden origin) konfiguriert. Dieses entspricht dem linked-swissbib/vufind Repo:
cd /usr/local/vufind/httpd
git remote add lsb https://github.com/linked-swissbib/vufind.git
git fetch lsb
git branch upstream lsb/vfsb/linked
An dieser Stelle kann ein VirtualBox Snapshot nicht schaden.
Ins richtige Verzeichnis wechseln:
cd /usr/local/vufind/httpd
git checkout vfsb/linked
git pull
Commit-Hash bestimmen, welcher übernommen werden soll: Über https://github.com/htw-pk15/vufind/commits/vfsb/linked oder mit
git log
bzw.
git show
Sollen mehrere Commits übernommen werden, alle notieren und im weiteren Verlauf mit dem ältesten Commit beginnen. Dabei ist zu beachten, dass Merge-Commits nicht notiert werden sollen. (Merge commits entstehen u.a. dann, wenn man in ein Repo pushen möchte, jemand einem aber zuvorgekommen ist und man deshalb git pull ausführt.)
git checkout upstream
git pull
git cherry-pick -n -x 1111111 # ältester commit zuerst
-
-n: Commit nicht sofort ausführen -
-x: Commit-Hash, welcher cherry-picked wurde, in der Commit-Nachricht notieren
Falls eine Fehlermeldung im Stil von error: could not apply 1111111... auftritt, konnte der cherry-pick nicht fehlerfrei durchgeführt werden, da eine oder mehrere Dateien bereits im linked-swissbib/vufind Repo geändert wurden. In diesem Fall müssen Merge-Konflikte aufgelöst werden, siehe dazu separaten Abschnitt in diesem Dokument. Im Fall, dass alles gut läuft, weiterlesen im Abschnitt "Änderungen committen".
Möchte man nicht fortfahren, kann alternativ der cherry-pick abgebrochen werden mit:
git cherry-pick --abort
Dateien, welche durch den cherry-pick Versuch geändert wurden, können mit
git reset HEAD dateiname
zurückgesetzt werden. Welche Dateien betroffen sind, zeigt der Befehl:
git status
Diese Fehlermeldung tritt auf, wenn versucht wurde, ein Merge-Commit zu cherry-picken. Ein Merge-Commit ein einer, welcher mehrere Vorgänger hat. Bei einem solchen Commit weiss git beim cherry-picken nicht, zu welchem Vorgänger-Stand (-Hash) er einen Patch/Diff erstellen soll, da der Commit ja mehrere Vorgänger hat. Merge-Commits sollten aber sowieso nicht cherry-picked werden (siehe oben). Wir müssen uns für einen Vorgänger entscheiden, mittels welchem der Patch erstellt werden soll. Dafür dient die Option -m. Hier kann aber nicht direkt ein Commit angegeben werden, sondern es muss eine sogenannte Parent-Nummer angegeben werden. (Bei einem Merge sind die zusammengeführten Commits die Parents und diese sind durchnummeriert.)
Mittels git log können wir einsehen, welche Parents der Commit hat, welchen wir cherry-picken wollen. (Sichtbar bei der Zeile, welche mit Merge: beginnt. Der erste vorkommende Commit hat die Nummer 1, die weiteren sind einfach hochgezählt. Wenn wir vorher schon einen Commit gecherry-pickt haben, der jetzt in dieser Liste der Parents vorkommt, so wählen wir diesen commit (bzw. dessen parent-Nummer).
Entsprechend lautet dann der durchzuführende Befehl: git cherry-pick -m Z -n -x 1111111 # Z = parent-Nummer
Das durchgestrichene Vorgehen ist problematisch und das entsprechende Verhalten von git nicht-intuitiv. Siehe http://stackoverflow.com/a/9229393 (inkl. den niedrig-bewerteten Kommentaren).
git commit
git push lsb HEAD:vfsb/linked
Sofern mehr als ein Commit cherry-picked werden soll, nochmals zum Befehl git cherry-pick zurückkehren und die Schritte wiederholen.
git checkout vfsb/linked
Es kann sein, dass ein cherry-pick nicht sauber angewandt werden kann. Das ist dann der Fall wenn der Vorgängerzustand vom gewünschten Commit nicht demjenigen Zustand entspricht, auf welcher der cherry-Pick angewandt werden soll. In diesem Fall gibt es in einer oder mehreren Dateien einen Merge-Konflikt, welcher manuell aufgelöst werden muss.
Mit dem Befehl
git status
werden unter both modified: die vom Merge-Konflikt betroffenen Dateien aufgelistet.
Jede betroffene Datei wird mit einem Text-Editor (nano, PhpStorm, gedit, ...) geöffnet. An mindestens einer Stelle wird ein Marker mit folgendem Aufbau sichtbar sein:
<<<<<<< HEAD
Variante 1
=======
Variante 2
>>>>>>> 1d2afb7fd96200cf2c2abebeaa86247f443e9e8c
Alle Zeilen, welche <, > oder = enthalten, müssen gelöscht werden. Ebenfalls gelöscht werden muss diejenige Variante, welche nicht erwünscht ist. Zurück bleibt also nur diejenige Variante welche erwünscht ist. Anders gesagt: Die Text-Datei muss so abgeändert werden, damit sie so aussieht, wie sie neu abgelegt werden soll. Im Extremfall kann das auch heissen, dass Text von Variante 1 und Variante 2 kombiniert werden muss.
Normalerweise können wir davon ausgehen, dass wir die gecherry-pickte Variante der aktuell vorliegenden Variante vorziehen möchten. Dies machen wir mit dem Befehl:
git checkout --theirs meinedatei
Dadurch wird die cherry-pick Variante der entsprechenden Datei ins working directory kopiert. Das Ergebnis ist dasselbe, wie wenn wir die Variante 1 der Konfliktbehebung durchführen (und dabei jeweils die cherry-pick Variante wählen). Der Vorteil von Variante 2 der Konfliktbehebung ist jedoch, dass keine "Handarbeit" an der Datei vorkommt. So sollten anschliessende cherry-picks sauber auf dieser Datei aufbauen können.
Um zu kennzeichnen, dass der Konflikt behoben ist, wird die betroffene Datei mittels
git add meinedatei
zur Staging Area hinzugefügt.
Achtung Dieser Schritt darf erst durchgeführt werden, wenn der Konflikt tatsächlich behoben worden ist. Andernfalls werden die Marker ebenfalls in Git abgelegt und Chaos bricht aus...
Die Behebung der Konflikte muss nun für jede Datei wiederholt werden. Anschliessend kann mit git commit der cherry-pick commitet (und anschliessend gepusht) werden.