git "merge --theirs"

[Marc Haber]

Hallo,

ich habe hier die folgende Situation: Gegeben sei eine Webapplikation
S, die von ihren Autoren bevorzugt als git Repository released wird.

Ich habe das Repository im Webspace gecloned, das damals gewünschte
Releasetag 2.3.5 ausgecheckt (git checkout v2.3.5) und in einen branch
"prod" kopiert (git checkout -b prod).

Nun hat die Webanwendung während ihres Betriebs
(1) sowohl Daten nach "prod/uploads" geschrieben,
(2) eine Library in "prod/zend-framework" aktualisiert und
(3) zahlreiche Plugins in "prod/plugins", die ursprünglich auch schon
im ersten Clone enthalten waren, aktualisiert.

Die Verzeichnisse, in die die Applikation während ihres regulären
Betriebs hineinschreibt wie prod/uploads, stehen in einem .gitignore,
das praktischerweise direkt mit dem Clone kam.

Wenn ich jetzt auf die Version 2.4 aktualisieren möchte, mache ich
"git stash save", und habe danach eine saubere working copy, in der
"git checkout master", "git pull", "git checkout v2.4" dann
funktioniert.

Fragenkomplex 1:
Um die Änderungen nun in meinen "prod"-Branch hineinzubekommen,
versuche ich "git checkout prod", "git rebase v2.4" und bekomme eine
Riesenlatte an rebase Konflikten.

Wenn ich git rebase richtig verstanden habe, nimmt sich git rebase die
Commits seit dem "git checkout -b prod", wechselt auf eine Kopie von
v2.4 und versucht meine Commits dann darauf anzuwenden. Mit welchem
Kommando kann ich mir diese Commits ansehen um zu schauen, wo diese
Konflikte herkommen? Oder habe ich da etwas falsch verstanden?

Fragenkomplex 2:
Auch "git checkout prod", "git merge v2.4" endet in einer laaaaangen
Liste von Mergekonflikten.

Kann ich git hier sagen, dass es im Fall eines Mergekonflikts einfach
die komplette Datei aus v2.4 übernehmen soll und "meine" lokalen
Änderungen in prod ignorieren soll? "git merge -s theirs" gibt es
nicht, und git merge -X theirs hilft nicht bei der Problematik, das
gibt auch hunderte von Mergekonflikten.

Die manpage von git merge unter "MERGE STRATEGIES" ist mir zu hoch,
und die im Netz ergooglebaren Texte zu dem Thema besprechen alle nur
den Trivialfall und hören dort auf, wo das Thema interessant wird. Und
das, was auf stackoverflow als Ersatz für git merge -s theirs
vorgeschlagen wird, ist hoffentlich nicht ernst gemeint
(unverständlich).

Fragenkomplex 3:
Diese Aufgabe "nimm alles aus dem anderen Branch was es dort gibt und
lasse nur meine Änderungen da für die es im anderen Branch keine
Neuerungen/Daten gibt" kommt in meiner Git-Welt mehrmals im Jahr vor,
es kann doch kaum angehen dass es für diesen usecase keine einfache
boilerplate-Standardlösung gibt, gerne für jedes Unterverzeichnis
einzeln?

Grüße
Marc

[Arno Welzel]

Post by Marc Haber
ich habe hier die folgende Situation: Gegeben sei eine Webapplikation
S, die von ihren Autoren bevorzugt als git Repository released wird.
Ich habe das Repository im Webspace gecloned, das damals gewünschte
Releasetag 2.3.5 ausgecheckt (git checkout v2.3.5) und in einen branch
"prod" kopiert (git checkout -b prod).
Nun hat die Webanwendung während ihres Betriebs
(1) sowohl Daten nach "prod/uploads" geschrieben,
(2) eine Library in "prod/zend-framework" aktualisiert und
(3) zahlreiche Plugins in "prod/plugins", die ursprünglich auch schon
im ersten Clone enthalten waren, aktualisiert.
Die Verzeichnisse, in die die Applikation während ihres regulären
Betriebs hineinschreibt wie prod/uploads, stehen in einem .gitignore,
das praktischerweise direkt mit dem Clone kam.
Wenn ich jetzt auf die Version 2.4 aktualisieren möchte, mache ich
"git stash save", und habe danach eine saubere working copy, in der
"git checkout master", "git pull", "git checkout v2.4" dann
funktioniert.

git checkout master --> stelle um auf existierenden Branch "master"
git pull --> hole alle änderungen im aktuelle Branch
git checkout v2.4 --> stelle um auf existierenden Branch "v2.4"

Bist Du sicher, dass das das gewünschte Ergebnis ist? Wozu pullst Du
erst master um dann auf v2.4 zu wechseln.

Post by Marc Haber
Um die Änderungen nun in meinen "prod"-Branch hineinzubekommen,
versuche ich "git checkout prod", "git rebase v2.4" und bekomme eine
Riesenlatte an rebase Konflikten.

Ja, das geht auch nicht so.

Post by Marc Haber
Wenn ich git rebase richtig verstanden habe, nimmt sich git rebase die
Commits seit dem "git checkout -b prod", wechselt auf eine Kopie von
v2.4 und versucht meine Commits dann darauf anzuwenden. Mit welchem

Nein, umgekehrt.

Es nimmt alle commits von v2.4, die seit deinem checkout vorhanden sind
und versucht die dann einzubauen, *bevor* dene commits ausgeführt
wurden. Das geht natürlich nur, wenn deine commits nicht im Konflikt zu
Änderungen aus v2.4 stehen.

Post by Marc Haber
Kommando kann ich mir diese Commits ansehen um zu schauen, wo diese
Konflikte herkommen? Oder habe ich da etwas falsch verstanden?

Mach's einfach nicht!

Wenn Du auf dem Stand von v2.4 sein willst, denn gehe eben auf v2.4.
Wozu noch das irgendwo hin mergen?

Post by Marc Haber
Auch "git checkout prod", "git merge v2.4" endet in einer laaaaangen
Liste von Mergekonflikten.

Ja - weil das einfach zwei verschiedene Versionen sind, die erstmal
nichts miteinander zu tun haben.

Generell ist dieses Herangehensweise völlig unsinnig. Eine
Webapplikation sollte reguläre Versions-Releases haben und nicht per
"git pull" aktualisiert werden. Und wenn das unbedingt so sein soll,
dann mit Versions-Branches, auf die man einfach per "git checkout" wechselt:

git fetch
git stash
git checkout v2.4
git stash pop

Aber wie gesagt: ich halte das als "Deployment"-Methode für hochgradigen
Unfug. Git ist für sowas nicht gedacht.

[Marcel Mueller]

Post by Arno Welzel

Post by Marc Haber
Wenn ich jetzt auf die Version 2.4 aktualisieren möchte, mache ich
"git stash save", und habe danach eine saubere working copy, in der
"git checkout master", "git pull", "git checkout v2.4" dann
funktioniert.

git checkout master --> stelle um auf existierenden Branch "master"
git pull --> hole alle änderungen im aktuelle Branch
git checkout v2.4 --> stelle um auf existierenden Branch "v2.4"
Bist Du sicher, dass das das gewünschte Ergebnis ist? Wozu pullst Du
erst master um dann auf v2.4 zu wechseln.

Ack. Das geht auch ohne.

Post by Arno Welzel
Generell ist dieses Herangehensweise völlig unsinnig. Eine
Webapplikation sollte reguläre Versions-Releases haben und nicht per
"git pull" aktualisiert werden. Und wenn das unbedingt so sein soll,
git fetch
git stash
git checkout v2.4
git stash pop
Aber wie gesagt: ich halte das als "Deployment"-Methode für hochgradigen
Unfug. Git ist für sowas nicht gedacht.

Die Aussage finde ich überzogen. Wenn man es richtig macht, kann das
eine sehr effiziente Methode sein. Gerade für Technologien, die entweder
Interpretersprachen nutzen oder Auf dem Zielsystem automatisch zur
Architektur passende Binaries erstellen eignet sich ein VCS sehr gut für
Deployment.

Wir haben das vor vielen Jahren schon für Mercator alias IBM WebSphere
TX gemacht, früher noch mit CVS, und dafür Lob vom Wirtschaftsprüfer
bekommen. Man kann damit die Nachvollziehbarkeit und das 4-Augen-Prizip
hervorragend umsetzen.
Die Freigabe eines Softwarestands für die QA erfolgt durch einen Merge
in den QA-Branch. Das Deployment auf die QA-Maschienen durch ein Pull
auf selbigen. Wenn die QA durch ist, folgt die Freigabe über den Merge
in den Prod-Branch, und der Rollout auf die Produktionsmaschienen kann
dann vom Operativen Personal angestoßen werden. Und wenn es wirklich mal
ein kritisches Problem in der Produktion gibt, kann es auch mal Hotfixes
geben, die direkt am QA-Branch ansetzen. Was auch immer passiert ist,
ist im Nachhinein gut nachvollziehbar und auch einigermaßen
manipulationssicher.

Ich kenne auch andere Firmen, die einen solchen Ansatz gewählt haben.
Eine hat sogar für jeden Kunden einen eigenen Branch gehabt, in dem sein
jeweiliger Versionsstand drin war inklusive eventueller
kundenspezifischer Erweiterungen.

Letztlich setzen alle Continous Integration Ansätze (von denen ich wenig
halte) auf einem vergleichbaren Prinzip auf, nur dass da aus technischen
Gründen noch ein Build-Server dazwischen kommt.


Marcel

[Marc Haber]

Post by Marcel Mueller

Post by Arno Welzel

Post by Marc Haber
Wenn ich jetzt auf die Version 2.4 aktualisieren möchte, mache ich
"git stash save", und habe danach eine saubere working copy, in der
"git checkout master", "git pull", "git checkout v2.4" dann
funktioniert.

git checkout master --> stelle um auf existierenden Branch "master"
git pull --> hole alle änderungen im aktuelle Branch
git checkout v2.4 --> stelle um auf existierenden Branch "v2.4"
Bist Du sicher, dass das das gewünschte Ergebnis ist? Wozu pullst Du
erst master um dann auf v2.4 zu wechseln.

Ack. Das geht auch ohne.

Ich bin mit git pull echt vorsichtig weil ich Angst habe dass mir ein
Pull einen merge in einem Branch auslöst, den ich gar nicht verändert
haben möchte. Und das v2.4 Tag ist halt erst mit dem Pull gekommen.

Es ist für mich einfacher, eine überflüssige Zeile zu tippen als mir
Gedanken darüber zu machen was für Gefahren entstehen könnten wenn ich
diese Zeile nicht tippe. Es ist ja nicht so, dass das Repository so
groß ist dass das eine git checkout zwei Stunden braucht.

Post by Marcel Mueller

Post by Arno Welzel
Generell ist dieses Herangehensweise völlig unsinnig. Eine
Webapplikation sollte reguläre Versions-Releases haben und nicht per
"git pull" aktualisiert werden. Und wenn das unbedingt so sein soll,
git fetch
git stash
git checkout v2.4
git stash pop
Aber wie gesagt: ich halte das als "Deployment"-Methode für hochgradigen
Unfug. Git ist für sowas nicht gedacht.

Die Aussage finde ich überzogen. Wenn man es richtig macht, kann das
eine sehr effiziente Methode sein. Gerade für Technologien, die entweder
Interpretersprachen nutzen oder Auf dem Zielsystem automatisch zur
Architektur passende Binaries erstellen eignet sich ein VCS sehr gut für
Deployment.

Danke, so sehe ich das auch. Die Autoren von git stellen sich gerne
auf den Kopf um zu sagen dass git kein Deplyoment-Tool ist; dennoch
wird es tausendffach dafür eingesetzt. Schließlich geht es auch nur
darum, dass am Ende ein Dateibaum in der gewünschten Form an einer
bestimmten Stelle im Dateisystem liegt.

Einen tarball darüber auszupacken ist übrigens genau so problematisch:
Das überschreibt im Zweifel lokal veränderte Dateien ohne Rückfrage
und Dateien die im Tarball geöscht wurden bleiben erhalten.

Wir benutzen git zum Softwaredeployment weil wir schlicht nichts
besseres haben. Oder?

Post by Marcel Mueller
Die Freigabe eines Softwarestands für die QA erfolgt durch einen Merge
in den QA-Branch.

d.h. der QA-Branch wird von jemandem beschrieben, der nicht in QA
arbeitet?

Post by Marcel Mueller
Das Deployment auf die QA-Maschienen durch ein Pull
auf selbigen. Wenn die QA durch ist, folgt die Freigabe über den Merge
in den Prod-Branch, und der Rollout auf die Produktionsmaschienen kann
dann vom Operativen Personal angestoßen werden. Und wenn es wirklich mal
ein kritisches Problem in der Produktion gibt, kann es auch mal Hotfixes
geben, die direkt am QA-Branch ansetzen. Was auch immer passiert ist,
ist im Nachhinein gut nachvollziehbar und auch einigermaßen
manipulationssicher.

... und wenn man irgend eine andere Methodik hätte, den Code aus dem
Branch des VCS auf die QA- oder Produktionssysteme zu transportieren
(notfalls baut man ein RPM draus), wäre es dasselbe.

Post by Marcel Mueller
Letztlich setzen alle Continous Integration Ansätze (von denen ich wenig
halte) auf einem vergleichbaren Prinzip auf, nur dass da aus technischen
Gründen noch ein Build-Server dazwischen kommt.

Genau.

Und das vorliegende Problem kommt daher, dass Webanwendungen zu oft
keine Trennung zwischen ausgeliefertem Code, zur Laufzeit
heruntergeladenem Code und Benutzerdaten haben.

Es ist ja nicht so, als bestünde diese Problematik nur für diese eine
Webapplikation. Ich glaube, wegen sowas haben wir docker.

Grüße
Marc

[Christian Garbs]

Mahlzeit!

Post by Marc Haber

Post by Marcel Mueller
Letztlich setzen alle Continous Integration Ansätze (von denen ich
wenig halte) auf einem vergleichbaren Prinzip auf, nur dass da aus
technischen Gründen noch ein Build-Server dazwischen kommt.

Genau.
Und das vorliegende Problem kommt daher, dass Webanwendungen zu oft
keine Trennung zwischen ausgeliefertem Code, zur Laufzeit
heruntergeladenem Code und Benutzerdaten haben.
Es ist ja nicht so, als bestünde diese Problematik nur für diese eine
Webapplikation. Ich glaube, wegen sowas haben wir docker.

Ich glaube, S wird aktuell auch dem "läuft eh in einem Container"-
Paradigma entwickelt.


Mein MediaWiki läuft mit einem DB-User, der keine GRANTs für CREATE,
DROP, ALTER usw. hat. Das beißt mich bei jedem Debian-Update in den
Arsch, weil ich das während des Updates kurz ändern muss, aber
dazwischen kann ich ruhig schlafen.


Bei S geht das nicht, denn die Plugins machen z.B. DB-Updates ganz
explizit "irgendwann" (so in der Art "ich probiere es jedes Mal, wenn
.php aufgerufen wird"). Da lassen sich die Rechte gar nicht richtig
beschneiden (oder nur mit vielen Schmerzen).


Immerhin braucht der PHP-User im Betrieb nur Schreibrechte auf Upload-
und Cache-Ordner. Wenn man die Updates (Anwendung + Plugins) manuell
einspielt, kann man wenigstens das Filesystem verrammeln. (Passt
wunderbar dazu, die verramelten Verzeichnisse dann ins git zu packen.)


Gruß
Christian

[Marc Haber]

Post by Christian Garbs
Ich glaube, S wird aktuell auch dem "läuft eh in einem Container"-
Paradigma entwickelt.

Das passt aber nicht dazu dass es kein offizieles Docker-Image gibt.

Grüße
Marc

[Arno Welzel]

[...]

Post by Marc Haber

Post by Marcel Mueller

Post by Arno Welzel
Aber wie gesagt: ich halte das als "Deployment"-Methode für hochgradigen
Unfug. Git ist für sowas nicht gedacht.

Die Aussage finde ich überzogen. Wenn man es richtig macht, kann das
eine sehr effiziente Methode sein. Gerade für Technologien, die entweder
Interpretersprachen nutzen oder Auf dem Zielsystem automatisch zur
Architektur passende Binaries erstellen eignet sich ein VCS sehr gut für
Deployment.

Danke, so sehe ich das auch. Die Autoren von git stellen sich gerne
auf den Kopf um zu sagen dass git kein Deplyoment-Tool ist; dennoch

Wenn selbst die Autoren von Git das sagen, wird das Gründe haben. Denn
sie berücksichtigen diese Anwendungsform nicht.

Post by Marc Haber
wird es tausendffach dafür eingesetzt. Schließlich geht es auch nur
darum, dass am Ende ein Dateibaum in der gewünschten Form an einer
bestimmten Stelle im Dateisystem liegt.

Eben - und genau darum geht es bei Deployment eben *nicht*. Es soll
nicht nur irgendein Dateibaum irgenwo liegen, sondern die Anwendung soll
in einem definierten Zustand sein. Das *kann* damit erreicht werden,
dass Dateien irgendwo hinkopiert werden, aber oft reicht das alleine
eben *nicht*. Genau deshalb gibt es Paketverwaltungen, die mehr machen,
als einfach nur Dateien irgendwo hin zu kopieren.

[...]

Post by Marc Haber
Und das vorliegende Problem kommt daher, dass Webanwendungen zu oft
keine Trennung zwischen ausgeliefertem Code, zur Laufzeit
heruntergeladenem Code und Benutzerdaten haben.

Das ist dann aber ein Problem der spezifischen Anwendung. Man kann auch
bei Webanwendungen sehr leicht Code und Benutzerdaten trennen. Nur weil
manche Leute glauben, dass "Webanwendung" bedeutet, dass alles in einem
Ordner liegen muss, weil bei Massen-Webhostern nichts anderes vorgesehen
ist, wird das nicht richtiger.

Post by Marc Haber
Es ist ja nicht so, als bestünde diese Problematik nur für diese eine
Webapplikation. Ich glaube, wegen sowas haben wir docker.

Docker hat mit Webanwendungen auch nicht viel zu tun, sondern ist
erstmal nur eine Form von Container. Ob die Daten da separat vorgehalten
werden oder nicht, ist auch vom Anbieter der Anwendung abhängig.

[Peter J. Holzer]

Post by Arno Welzel

Post by Marc Haber
Danke, so sehe ich das auch. Die Autoren von git stellen sich gerne
auf den Kopf um zu sagen dass git kein Deplyoment-Tool ist; dennoch

Wenn selbst die Autoren von Git das sagen, wird das Gründe haben.

"Ein Tool ist dann erfolgreich, wenn es für Dinge verwendet wird, die
der Autor nicht vorgesehen hatte."

Von wem war der Spruch noch mal?

hp

[Christian Garbs]

Mahlzeit!

Post by Arno Welzel
Aber wie gesagt: ich halte das als "Deployment"-Methode für hochgradigen
Unfug. Git ist für sowas nicht gedacht.

Ob git für Deployments gedacht war, vermag ich nicht zu beurteilen,
aber man kann es prima dafür benutzen:

Ich hatte mal ein paar Jahre etwas im Einsatz, um einen kleine
Webseite zu deployen, mit einem Staging-Bereich zur Abnahme durch den
"Kunden" sowie dem Produktivstand.

https://github.com/mmitch/gbdt

Komplett git-basierter Deployment-Workflow, hat perfekt funktioniert.
Seitdem aber nie wieder benutzt, weil ich das nicht mehr brauche.

Gruß
Christian

[Christian Garbs]

Mahlzeit!

Post by Marc Haber
ich habe hier die folgende Situation: Gegeben sei eine
Webapplikation S, die von ihren Autoren bevorzugt als git Repository
released wird.

Falls es sich dabei um eine Blogsoftware handelt (der Buchstabe und
die Versionsnummern lassen darauf schließen), wärst Du an meinem
Workflow dafür interessiert?

Ich hab verschiedene Branches für Upstream, lokale Konfiguration
(DB-Passwort, Plugins usw.), eigene Plugins und lokale Änderungen.

Dazu ein Shellskript, dass die stapelweise aufeinander rebased.
Das ist total stumpf, klappt aber erstaunlich gut.

(Die Antwort dazu könnte ich parellel im Blog veröffentlichen, was
dann leider dazu führt, dass sie ewig dauern wird, weil ich mit
Blogartikeln total schnarchig bin…)

Gruß
Christian

[Marc Haber]

Post by Christian Garbs

Post by Marc Haber
ich habe hier die folgende Situation: Gegeben sei eine
Webapplikation S, die von ihren Autoren bevorzugt als git Repository
released wird.

Falls es sich dabei um eine Blogsoftware handelt (der Buchstabe und
die Versionsnummern lassen darauf schließen),

Richtig geraten. Zeit hat die Sache im Moment, weil S auf Debian
Bullseye mit PostgreSQL als Datenbank sowieso nicht läuft (man benutzt
ein seit 2005 abgekündigtes PostgreSQL-Feature, das vermutlich eh
nicht benötigt wird, der entsprechende Bug ist seit letztem Jahr
offen).

Realistisch gesehen wird die VM, auf der S läuft, auf absehbare Zeit
mein Bullseye-Einhorn sein, die anderen Maschinen sind alle
aktualisiert worden.

Post by Christian Garbs
wärst Du an meinem
Workflow dafür interessiert?

Aber selbstverständlich.

Post by Christian Garbs
Ich hab verschiedene Branches für Upstream, lokale Konfiguration
(DB-Passwort, Plugins usw.), eigene Plugins und lokale Änderungen.
Dazu ein Shellskript, dass die stapelweise aufeinander rebased.
Das ist total stumpf, klappt aber erstaunlich gut.

Hast Du auch einen Weg um vom klassischen Layout auf Deinen Weg
umzusteigen?

Post by Christian Garbs
(Die Antwort dazu könnte ich parellel im Blog veröffentlichen, was
dann leider dazu führt, dass sie ewig dauern wird, weil ich mit
Blogartikeln total schnarchig bin…)

Ja, das Blog einfach in die Tonne zu treten wäre eine Option.
Microblogging¹ hat mein Bedürfnis mich in längeren Artikel mitzuteilen
ziemlich effektiv abgeschafft².

Grüße
Marc

¹ vor einem Jahr hätte ich jetzt noch "Twitter" geschrieben.
² oder nahe auf Null reduziert

[Christian Garbs]

Mahlzeit!

Post by Marc Haber

Post by Christian Garbs
Falls es sich dabei um eine Blogsoftware handelt (der Buchstabe und
die Versionsnummern lassen darauf schließen),

Richtig geraten. Zeit hat die Sache im Moment, weil S auf Debian
Bullseye mit PostgreSQL als Datenbank sowieso nicht läuft (man
benutzt ein seit 2005 abgekündigtes PostgreSQL-Feature, das
vermutlich eh nicht benötigt wird, der entsprechende Bug ist seit
letztem Jahr offen).

Was arbeitest Du auch mit einer richtigen Datenbank :-)
Ich glaube, so richtig getestet wird nur noch mit SQLite.

Ich habe letzten Monat einen Bug im Spambayes-Plugin gefixt, der nur
unter MySQL/MariaDB auftritt. Und der war da schon länger drin, ich
hab ihn nur als erster gefunden.

Ich will da jetzt nicht tiefer reinsteigen (ich hab ja auch gar kein
PostgreSQL), aber die OIDs kann man wohl durch normale Sequences
ersetzen[1] und dann wäre vermutlich (nur 5 Minuten Code überfliegen)
nur die Methode S_db_insert_id() anzupassen in der postgres.inc.php

[1] https://dba.stackexchange.com/questions/259359/eliminating-oids-while-upgrading-postgresql-from-9-4-to-12

Post by Marc Haber
Realistisch gesehen wird die VM, auf der S läuft, auf absehbare Zeit
mein Bullseye-Einhorn sein, die anderen Maschinen sind alle
aktualisiert worden.

Post by Christian Garbs
wärst Du an meinem Workflow dafür interessiert?

Aber selbstverständlich.

Ich versuch mich zu beeilen :)

Post by Marc Haber
Hast Du auch einen Weg um vom klassischen Layout auf Deinen Weg
umzusteigen?

Das müsste gehen.

Die Plugins kannst Du ja am Stück kopieren (alles, was unter /plugins
liegt, gehört bei mir in den entsprechenden Branch) und falls Du
Änderungen gegenüber dem Upstream gemacht hast, kannst Du Dir ein Diff
machen und das dann in den entsprechenden Branch tun.

Post by Marc Haber
Microblogging¹ hat mein Bedürfnis mich in längeren Artikel mitzuteilen
ziemlich effektiv abgeschafft².

Ist bei mir genau anders herum, gerade jetzt, wo Twitter so blöd
geworden ist. Ich freu mich über alles, was ich in meinem Blog habe
(meine Daten sind bei mir, die will keiner verkaufen) und schreibe
außer im Usenet eigentlich nirgendwo sonst mehr. Leider halt auch
nicht häufiger in meinem Blog…

Bevor ich mal ins Gras beiße, muss ich das Blog noch irgendwie nach
GitHub kippen, dann bleibt's verfügbar, auch wenn ich meine
Servermiete nicht mehr zahle ;-)

Gruß
Christian

[Stefan+ (Stefan Froehlich)]

Post by Christian Garbs

Post by Marc Haber

Post by Christian Garbs
Falls es sich dabei um eine Blogsoftware handelt (der Buchstabe
und die Versionsnummern lassen darauf schließen),

Richtig geraten. Zeit hat die Sache im Moment, weil S auf Debian
Bullseye mit PostgreSQL als Datenbank sowieso nicht läuft (man
benutzt ein seit 2005 abgekündigtes PostgreSQL-Feature, das
vermutlich eh nicht benötigt wird, der entsprechende Bug ist seit
letztem Jahr offen).

Jetzt musste ich doch nachgucken, weil PostgreSQL ja eigentlich so
gut wie nie irgendein Feature abkündigt.

Post by Christian Garbs
Ich will da jetzt nicht tiefer reinsteigen (ich hab ja auch gar
kein PostgreSQL), aber die OIDs kann man wohl durch normale
Sequences ersetzen[1] und dann wäre vermutlich (nur 5 Minuten Code
überfliegen) nur die Methode S_db_insert_id() anzupassen in der
postgres.inc.php
[1] https://dba.stackexchange.com/questions/259359/eliminating-oids-while-upgrading-postgresql-from-9-4-to-12

Ich sehe da in include/db/postgres.inc.php zwei Aufrufe von
pg_last_oid(), was darauf schließen lässt, dass man 1:1 von MySQL
portiert hat, um sich nur ja nicht anpassen zu müssen.

Das klappt ohne OIDs nicht mehr und ließe sich rein DB-seitig nur
lösen, wenn man die Indizes streng nach Konvention benennt und statt
pg_last_oid() mit currval() den jeweiligen Index abfrägt. Unschön.

Eigentlich will man hier INSERT RETURNING haben, was der Code auf
den ersten Blick aber nicht (einfach) hergibt.

Andere Idee: include/db/pdo-postgres.inc.php sieht diesbezüglich
besser aus, verwendet currval() und enthält keine einzige Abfrage
der OID. Also vielleicht damit?

Servus,
Stefan

[Marc Haber]

Post by Marc Haber
Richtig geraten. Zeit hat die Sache im Moment, weil S auf Debian
Bullseye mit PostgreSQL als Datenbank sowieso nicht läuft (man benutzt
ein seit 2005 abgekündigtes PostgreSQL-Feature, das vermutlich eh
nicht benötigt wird, der entsprechende Bug ist seit letztem Jahr
offen).

Ich meinte oben (und vor einem jahr) bookworm, und die aktuelle
Version läuft auch in bookworm, zusammen mit einem bookworm
PostgreSQL.

Grüße
Marc

[Thomas Hochstein]

Post by Christian Garbs

Post by Marc Haber
ich habe hier die folgende Situation: Gegeben sei eine
Webapplikation S, die von ihren Autoren bevorzugt als git Repository
released wird.

Falls es sich dabei um eine Blogsoftware handelt (der Buchstabe und
die Versionsnummern lassen darauf schließen), wärst Du an meinem
Workflow dafür interessiert?

Huh? Diese Blogsoftware wird als .zip-Datei releast (und als .tar.gz).

[Marc Haber]

Post by Thomas Hochstein

Post by Christian Garbs

Post by Marc Haber
ich habe hier die folgende Situation: Gegeben sei eine
Webapplikation S, die von ihren Autoren bevorzugt als git Repository
released wird.

Falls es sich dabei um eine Blogsoftware handelt (der Buchstabe und
die Versionsnummern lassen darauf schließen), wärst Du an meinem
Workflow dafür interessiert?

Huh? Diese Blogsoftware wird als .zip-Datei releast (und als .tar.gz).

Und es wird sehr deutlich empfoheln, doch aus einem git-Snapshot zu
arbeiten. Auch der Release als tar.gz löst nicht das Problem der
unterwegs nachgeladenen Dateien und von Dateien, die in Release X
enthalten, in X+1 aber nicht mehr enthalten sind.

Grüße
Marc

[Christian Garbs]

Mahlzeit!

Post by Marc Haber

Post by Thomas Hochstein
Huh? Diese Blogsoftware wird als .zip-Datei releast (und als .tar.gz).

Und es wird sehr deutlich empfoheln, doch aus einem git-Snapshot zu
arbeiten. Auch der Release als tar.gz löst nicht das Problem der
unterwegs nachgeladenen Dateien und von Dateien, die in Release X
enthalten, in X+1 aber nicht mehr enthalten sind.

Ich habe lange nicht in die offizielle Anleitung geguckt, aber wegen
eventuell gelöschter Dateien kann das Upgrade eigentlich nur ähnlich
wie bei Nextcloud laufen:

1. plugins/ templates_c/, und uploads/ verschieben/retten/sichern
2. alles löschen
3. neues ZIP entpacken
4. die Verzeichnisse wieder zurückschieben

(templates_c/ könnte man auch weghauen, ist eh nur Cache)


Ich hab mal eine zeitlang das alte ZIP (passend zur bei mir benutzten
Version) sowie das aktuelle ZIP (das Update) nebeneinander ausgepackt,
dann ein Diff erzeugt und dann dieses Diff über mein echtes Blog als
Patch verteilt. Kann man halbwegs automatisieren, ist aber auch
irgendwie umständlich.

Gab's nicht ganz viel früher sogar mal Diffs zum Runterladen?

Gruß
Christian

[Marc Haber]

Post by Christian Garbs
Ich habe lange nicht in die offizielle Anleitung geguckt, aber wegen
eventuell gelöschter Dateien kann das Upgrade eigentlich nur ähnlich
1. plugins/ templates_c/, und uploads/ verschieben/retten/sichern
2. alles löschen
3. neues ZIP entpacken
4. die Verzeichnisse wieder zurückschieben
(templates_c/ könnte man auch weghauen, ist eh nur Cache)

Neues ZIP drüberklatschen (die Konfigurationsdatei ist nicht
enthalten), Blog aufrufen, man landet dann automatisch im
Update-Assistenten, 2.3 => 2.4 will auch wirklich was machen, 2.4 =>
2.5 nicht. Beim ersten Login ins Admin-Frontent wird man dann
aufgefordert, die Plugins zu updaten.

Grüße
Marc

[Christian Garbs]

Mahlzeit!

Post by Christian Garbs

Post by Marc Haber
ich habe hier die folgende Situation: Gegeben sei eine
Webapplikation S, die von ihren Autoren bevorzugt als git Repository
released wird.

Falls es sich dabei um eine Blogsoftware handelt (der Buchstabe und
die Versionsnummern lassen darauf schließen), wärst Du an meinem
Workflow dafür interessiert?

Es folgt ein Crosspost von
https://www.cgarbs.de/blog/archives/1205-Wie-ich-mein-Serendipity-Blog-aktualisiere.html



Wie ich mein Blog aktualisiere
==============================

In [de.comp.os.unix.linux.misc] kam das Thema [Serendipity] (kurz:
s9y) zur Sprache, insbesondere wie man das Blog im git halten und dann
Updates einspielen kann. Da dieses Blog hier unter s9y läuft und ich
es mit git verwalte, folgt hier mein Senf zu dem Thema.

Ich will nicht behaupten, dass mein Weg besonders toll oder sinnvoll
ist, aber basierend auf meiner ganz persönlichen Erfahrung und dem
Blick in meine git-Historie hat das die letzten 15 Jahre ganz prima
funktioniert. Ich habe dabei die s9y-Updates von 1.2.0 bis 2.4.0
mitgenommen und die jeweils aktuellen Debian-Stables mit dem jeweils
dazugehörigen PHP.

Disclaimer: Ich habe vermutlich ebenfalls seit 15 Jahren nicht mehr in
die Anleitung geguckt, wie ein Update offiziell durchzuführen ist.


[de.comp.os.unix.linux.misc] <news:de.comp.os.unix.linux.misc>

[Serendipity] <https://s9y.org/>

Grundsätzliches zu meiner Installation
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Ich nutze keine Container oder sowas, s9y läuft einfach im Apache
unter dem PHP-User ([ich nutze php-fpm]) und die Daten liegen in der
hier laufenden MariaDB-Instanz (das scheint inzwischen ungewöhnlich zu
sein, s9y wird heutzutage wohl primär mit SQLite getestet und
entwickelt).

Da ich nicht möchte, dass der PHP-User überall schreiben darf und
irgendwelchen Unfug machen kann, habe ich einen zweiten User, dem alle
statischen Dateien gehören. Der PHP-User darf diese Dateien nur
lesen. Ausnahmen sind die beiden Verzeichnisse `templates_c/' (der
Template-Cache) und `uploads/' (Bilder usw., die übers Blog-Interface
hochgeladen werden): Hier ist es genau andersherum und nur der
PHP-User darf schreiben.

Ich habe /kein/ zweites Staging- oder Testblog, dafür habe ich zu
wenig Traffic. Wenn ich bastele, dann direkt im Live-Betrieb und wenn
was kaputtgeht, ist es kaputt. Ist halt nur ein kleines privates
Blog. Backups habe ich natürlich trotzdem.


[ich nutze php-fpm]
<https://www.cgarbs.de/blog/archives/1196-Update-auf-HTTP2.html>


git und mein Branchkonzept
~~~~~~~~~~~~~~~~~~~~~~~~~~

Ich habe mir eine wilde(?) Branchlogik überlegt, in die mein Blog
eingeteilt ist. Jeder Branch baut dabei auf dem vorherigen auf und
wird regelmäßig darauf gerebased:

1. `master' liegt ganz unten und enthält das eigentliche s9y, hier
sind die Upstream-Sourcen ausgepackt. Die mitgelieferte
`.gitignore' ist bereits passend.
2. `mitch' enthält meine lokale Konfiguration: hier ist die
`serendipity_config_local.inc.php' mit meiner DB-Konfiguration
eingecheckt (auch wenn sie eigentlich in der `.gitignore' steht)
und in diesem Branch ist das Verzeichnis `plugins/' mit den von mir
verwendeten Plugins gefüllt.
3. `mitch-extra' enthält Fixes, Korrekturen und Hacks, die ich auf die
installierten Plugins anwende. Jede Änderung wird einfach direkt
eingecheckt. Aktuell sind hier ein paar Farbanpassungen für
[serendipity_event_geshi] enthalten sowie kleinere Änderungen beim
Versand von E-Mails[1].
4. `catreegory' enthält mein eigenes [catreegory]-Plugin. Das ist
auch einfach stumpf nach `plugins/' kopiert, ich habe keinerlei
Automatismus, um das mit dem Plugin-Source-Repository synchron zu
halten. Da passieren eh keine Änderungen, wenn nicht gerade etwas
mit einer neuen PHP-Version kaputtgeht.
5. `twittercard' enthält noch ein eigenes Plugin – das habe ich seit
der Erschaffung in 2016 komplett vergessen (es ist auch nur ein
Commit – nie wieder angefasst). Es ist noch nicht mal auf GitHub
veröffentlicht, peinlich, peinlich… Das Plugin setzt ein paar
Metadaten in den HTML-Headern der Artikel, damit Twitter, Facebook
& Co. bei Links auf das Blog eine Überschrift, ein Bild
usw. extrahieren können (siehe [Twitter Cards] und [Open Graph
Protocol]).
6. `restyle' ist der dickste Batzen an Commits, da ist alles drin, was
ich am Blog geschraubt habe: CSS, Fonts, eigenes Template
([sowas]), Datenminimierung wegen DSGVO ([sowas]) usw.
7. `jquery-update' ist ein Update von JQuery auf eine weniger antike
Version. Das basiert auf dem seit drei Jahren offenen
[Pull-Request #687], aber inzwischen mit einer noch aktuelleren
JQuery-Version. Läuft mit den von mir benutzten Plugins seit den
drei Jahren ohne Probleme.


[serendipity_event_geshi]
<https://spartacus.s9y.org/index.php?mode=bygroups_event_en#serendipity_event_geshi>

[catreegory] <https://github.com/mmitch/catreegory>

[Twitter Cards]
<https://developer.twitter.com/en/docs/twitter-for-websites/cards/overview/abouts-cards>

[Open Graph Protocol] <https://ogp.me/>

[sowas]
<https://www.cgarbs.de/blog/archives/1124-Redesign-des-Blogs.html>

[sowas]
<https://www.cgarbs.de/blog/archives/1162-DSGVO-hier-im-Blog.html>

[Pull-Request #687] <https://github.com/s9y/Serendipity/pull/687>


Änderungen
~~~~~~~~~~

Wenn ich jetzt irgendetwas ändern will, dann checke ich den
entsprechenden Branch aus (z.B. `mitch', wenn sich meine DB-Connection
geändert hat), committe dort die Änderung und rebase dann alle
Branches aufeinander. Dafür gibt es dieses kleine Skript mit dem
passenden Namen `git-magic-blog':

,----
| git checkout mitch && git rebase master \
| && git checkout mitch-extra && git rebase mitch \
| && git checkout catreegory && git rebase mitch-extra \
| && git checkout twittercard && git rebase catreegory \
| && git checkout restyle && git rebase twittercard \
| && git checkout jquery-update && git rebase restyle \
| && git checkout jquery-update
`----

Das ist total eklig, funktioniert aber insgesamt super.

Etwas gewöhnungsbedürftig ist, wenn ein einzelner Commit wegfällt,
weil sich irgendwas im Original-Code geändert hat: Dann muss ich in
dem Branch, in dem mein Commit lag, beim Rebase einmal `git rebase
skip' aufrufen (so weit, so normal), und danach /in allen darauf
folgenden Branches noch einmal/. Das ist im ersten Moment
erschreckend und ungewöhnlich, bei genauerer Betrachtung aber logisch:
Der Commit war in allen darauf aufbauenden Branches drin und git
versucht bei jedem Folge-Rebase, ihn anzuwenden und stellt dann erneut
fest „hier ist ja gar nichts mehr zu tun, willst Du den Commit
überspringen?“.

Ebenso muss ich, wenn ich einen meiner Commits absichtlich droppe, ihn
auch in allen Folge-Branches noch einmal droppen.

Das muss man wissen und dran denken, damit kann ich aber gut leben.


„Wartungsmodus“
~~~~~~~~~~~~~~~

Während ich den Branch gewechselt habe, läuft das Blog mehr oder
weniger weiter, ggf. aber nur auf einem Reifen: Ist der Branch
`master' ausgecheckt, fehlt die DB-Konfiguration, da geht gar nichts
mehr. Ist `mitch' ausgecheckt, fehlen mein Catreegory-Plugin und mein
gesamtes CSS und so weiter. Das Blog sieht dann sehr rustikal aus,
funktioniert aber grundlegend.

Wie gesagt: Das ist hier kein wichtiger Produktivbetrieb, damit kann
ich leben. Man könnte das git-Repository natürlich genausogut
irgendwo hinreplizieren, dort lokal die Änderungen durchführen und
dann nacheinander alle Branches in den Produktivbetrieb force-pushen
(oder einfach den ausgecheckten Branch `jquery-updates' komplett auf
den Server rsync(1)en oder sowas).

Wenn ich z.B. etwas am CSS ändere, mache ich das im „kompletten Blog“
(also im Branch `jquery-updates') im laufenden Betrieb, bis es passt.
Visuelle Kontrolle direkt im Browser :)
Dann commit ich die Änderung, checke meinen `restyle'-Branch aus und
hole mir den Commit mit `git cherry-pick' dorthin. Danach einmal
`git-magic-blog' aufrufen und der doppelte Commit verschwindet
automatisch aus dem `jquery-updates'-Branch.


Updates
~~~~~~~

Da der PHP-User die Blog-Dateien nur lesen darf, kann ich kein Update
der Plugins über die Weboberfläche vornehmen. Stattdessen mache ich
Folgendes:

1. Branch `mitch' auschecken, das ist der für die Plugins.
2. Ich besorge mir das Plugin als .zip in der neuesten Version (in der
Admin-Seite „Plugins verwalten“ über den Link „Weitere
Informationen“ landet man auf der passenden Seite in [Spartacus]).
3. Ich lösche das alte Plugin mit einem beherzten `rm -r
plugins/serendipity_foo_bar'.
4. Ich packe das Archiv des neuen Plugins unterhalb von `plugins/'
aus.
5. Ggf. mache ich ein `chmod -R -x+rX' auf das Plugin-Verzeichnis
(vorher schaue ich einmal, wie die ausgepackten Daten aussehen).
6. Mit `git add plugins/' füge ich alle Änderungen in den Index hinzu.
7. Mit `git diff --staged' schaue ich noch einmal drüber, ob
irgendetwas komisch aussieht.
8. Mit `git commit' und einem Kommentar wie /updated plugin X to
version Y/ checke ich die Änderung ein.
9. Mit dem Skript `git-magic-blog' rebase ich alles aufeinander und
aktiviere wieder den „Komplettstand“ des Blogs im finalen Branch
`jquery-updates'.

Ein Update der Serendipity-Version selbst funktioniert genauso, nur
checke ich dann initial den Branch `master' aus und beackere alle
Verzeichnisse außer `plugins/', `templates_c/' und `uploads/'
(`plugins/' ist bei ausgechecktem `master'-Branch sowieso leer).

Da der PHP-User die eingeschränkten Schreibrechte hat, kann ich mir
sicher sein, dass außerhalb von `templates_c/' und `uploads/' im
laufenden Betrieb keine Dateien dazugekommen sind und so bei einem
Update ohne Rücksicht auf Verluste all das komplett löschen, was dann
aus dem Archiv wieder neu ausgepackt wird.

Durch das komplette löschen entferne ich auch Dateien, die in Version
n enthalten waren, in Version n+1 aber nicht mehr. Wenn man die ZIPs
nur über den alten Stand drüberkippt, bleiben eigentlich gelöschte
Dateien erhalten.


[Spartacus] <https://spartacus.s9y.org/index.php>


git und äh… CVS?
~~~~~~~~~~~~~~~~

Was mich bei Plugin-Updates regelmäßig stört, sind die neu
auftauchenden CSV-Unterverzeichnisse mit den jeweils drei Dateien
`Entries', `Repository' und `Root'. Die stecken in /jedem/
Verzeichnis in den Plugin-Archiven.

Es ist mir unklar, wie die dort hineinkommen, wo die Plugins doch
inzwischen so wie auch s9y selbst [in einem Git-Repository verwaltet
werden]. Da muss irgendwo noch alte Paketierungs-Infrastruktur am
Werk sein. Davon habe ich Upstream bisher noch nichts erzählt, aber
mal sehen, die lesen hier mit ;-)


[in einem Git-Repository verwaltet werden]
<https://github.com/s9y/additional_plugins/blob/master/emerge.sh>


Security
~~~~~~~~

Da ich meine lokale DB-Konfiguration im Branch `mitch' eingecheckt
habe, muss ich natürlich unbedingt sicherstellen, dass mein
`.git/'-Verzeichnis nicht vom Webserver ausgeliefert wird, sonst leakt
mein DB-Passwort.

Dafür gibt es mehrere Möglichkeiten:

- Man kann die `.htaccess' im Wurzelverzeichnis passend editieren.
- Man kann eine `git/.htaccess' anlegen, da reicht dann ein `Deny from
all' aus.
- Wenn man wie ich mit zwei Usern arbeitet, kann man dem PHP-User die
Leserechte durch ein `chmod 700 .git/' entziehen.
- Oder man verschiebt alles im git-Repo in ein Unterverzeichnis
(z.B. `serendipity/') und gibt dem Webserver nur Zugriff darauf.
Dann liegt `.git/' eine Ebene höher und ist nicht mehr erreichbar.
- (x) all of the above


Fazit
~~~~~

Ich mache das wie beschrieben und es funktioniert seit Ewigkeiten
prima.
YMMV.



Fußnoten
________

[1] Ich habe zwei Änderungen in `serendipity_sendMail()' gemacht: s9y
soll selbst keine Message-IDs erzeugen, das kann mein Mailserver
besser. Außerdem war irgendwas mit den Mailheadern komisch, ich habe
in einem `implode()' eine taktische Korrektur von `\n' auf `\r\n'
vorgenommen – das sollte ich vielleicht mal upstream zur Sprache
bringen.

[Stefan Reuther]

Post by Marc Haber
Nun hat die Webanwendung während ihres Betriebs
(1) sowohl Daten nach "prod/uploads" geschrieben,
(2) eine Library in "prod/zend-framework" aktualisiert und
(3) zahlreiche Plugins in "prod/plugins", die ursprünglich auch schon
im ersten Clone enthalten waren, aktualisiert.

(2) und (3) dürfte dir den rebase versauen.

Möglicherweise hilft es, diese Updates wegzuwerfen und nach dem Update
der Webanwendung neu einzuspielen (falls überhaupt noch nötig).

Post by Marc Haber
Wenn ich git rebase richtig verstanden habe, nimmt sich git rebase die
Commits seit dem "git checkout -b prod", wechselt auf eine Kopie von
v2.4 und versucht meine Commits dann darauf anzuwenden. Mit welchem
Kommando kann ich mir diese Commits ansehen um zu schauen, wo diese
Konflikte herkommen? Oder habe ich da etwas falsch verstanden?

git merge-base

Ansonsten klingt das, als ob du

git rebase --onto v2.4 v2.3.5 prod

suchst ("nimm die Änderungen von v2.3.5 -> prod und appliziere die auf
v2.4"). Disclaimer: (2) und (3) von oben.

Post by Marc Haber
Auch "git checkout prod", "git merge v2.4" endet in einer laaaaangen
Liste von Mergekonflikten.

Da wäre die Frage, wie die History wirklich aussieht.

Wenn der master eine lineare History von v2.3.5 ... v2.4 hat, sollte das
völlig schmerzfrei sogar als fast-forward merge gehen. Wenn die v2.3.5
aber bereits ein Branch ist, der z.B. rückportierte Fixes aus dem master
erhalten hat, bekommst du damit natürlich Konflikte (Bugfix auf master
vs. rückportierter Fix auf Release).

Post by Marc Haber
Diese Aufgabe "nimm alles aus dem anderen Branch was es dort gibt und
lasse nur meine Änderungen da für die es im anderen Branch keine
Neuerungen/Daten gibt" kommt in meiner Git-Welt mehrmals im Jahr vor,
es kann doch kaum angehen dass es für diesen usecase keine einfache
boilerplate-Standardlösung gibt, gerne für jedes Unterverzeichnis
einzeln?

Spontan aus der Hüfte geschossen:

git checkout anderer-branch -- $(git diff --name-only
alte-version-vom-anderen-branch anderer-branch)

Das vernichtet halt ggf. deine Änderungen, weswegen ich schon irgendwie
verstehen kann, dass man das nicht *zu* einfach macht.


Stefan

[Marc Haber]

Post by Stefan Reuther

Post by Marc Haber
Nun hat die Webanwendung während ihres Betriebs
(1) sowohl Daten nach "prod/uploads" geschrieben,
(2) eine Library in "prod/zend-framework" aktualisiert und
(3) zahlreiche Plugins in "prod/plugins", die ursprünglich auch schon
im ersten Clone enthalten waren, aktualisiert.

(2) und (3) dürfte dir den rebase versauen.

Auch wenn es nicht committed ist? Ich hatte versucht, die Änderungen
zu stashen und dann zu rebasen, geht aber auch incht :-(

Post by Stefan Reuther
Möglicherweise hilft es, diese Updates wegzuwerfen und nach dem Update
der Webanwendung neu einzuspielen (falls überhaupt noch nötig).

Bei den Plugins dürfte das nötig sein, ich fürchte obendrein um
Konfiguration.

Post by Stefan Reuther

Post by Marc Haber
Wenn ich git rebase richtig verstanden habe, nimmt sich git rebase die
Commits seit dem "git checkout -b prod", wechselt auf eine Kopie von
v2.4 und versucht meine Commits dann darauf anzuwenden. Mit welchem
Kommando kann ich mir diese Commits ansehen um zu schauen, wo diese
Konflikte herkommen? Oder habe ich da etwas falsch verstanden?

git merge-base
Ansonsten klingt das, als ob du
git rebase --onto v2.4 v2.3.5 prod
suchst ("nimm die Änderungen von v2.3.5 -> prod und appliziere die auf
v2.4").

Mit committeten oder gestashten Änderungen?

Post by Stefan Reuther

Post by Marc Haber
Auch "git checkout prod", "git merge v2.4" endet in einer laaaaangen
Liste von Mergekonflikten.

Da wäre die Frage, wie die History wirklich aussieht.

Magst ein tar.gz vom Repository?

Post by Stefan Reuther
Wenn der master eine lineare History von v2.3.5 ... v2.4 hat, sollte das
völlig schmerzfrei sogar als fast-forward merge gehen. Wenn die v2.3.5
aber bereits ein Branch ist, der z.B. rückportierte Fixes aus dem master
erhalten hat, bekommst du damit natürlich Konflikte (Bugfix auf master
vs. rückportierter Fix auf Release).

Sollte git nicht erkennen dass da ein Commit schon angewendet wurde?

Wie krieg ich am einfachsten raus ob es eine lineare History gibt?
Kann mir git merge-base da helfen, z.B. wenn 2.3.5 eine merge base von
2.3.5 und 2.4 ist?

Post by Stefan Reuther
git checkout anderer-branch -- $(git diff --name-only
alte-version-vom-anderen-branch anderer-branch)
Das vernichtet halt ggf. deine Änderungen, weswegen ich schon irgendwie
verstehen kann, dass man das nicht *zu* einfach macht.

Die könnte man sich ja vorher sichern wenn man wüsste um welche es
geht.

Grüße
Marc

[Christian Garbs]

Mahlzeit!

Post by Marc Haber

Post by Stefan Reuther
Möglicherweise hilft es, diese Updates wegzuwerfen und nach dem Update
der Webanwendung neu einzuspielen (falls überhaupt noch nötig).

Bei den Plugins dürfte das nötig sein, ich fürchte obendrein um
Konfiguration.

Die müsste eigentlich komplett in der Datenbank liegen. Bei mir darf
der PHP-User nicht nach plugins/ schreiben, da kann also nichts
relevantes sein.

Gruß
Christian

[Stefan Reuther]

Post by Marc Haber

Post by Stefan Reuther

Post by Marc Haber
Nun hat die Webanwendung während ihres Betriebs
(1) sowohl Daten nach "prod/uploads" geschrieben,
(2) eine Library in "prod/zend-framework" aktualisiert und
(3) zahlreiche Plugins in "prod/plugins", die ursprünglich auch schon
im ersten Clone enthalten waren, aktualisiert.

(2) und (3) dürfte dir den rebase versauen.

Auch wenn es nicht committed ist? Ich hatte versucht, die Änderungen
zu stashen und dann zu rebasen, geht aber auch incht :-(

Wenn die Änderungen alle nicht committed sind, hast du also aus Sicht
von git ein ausgechecktes Tag und ein paar Änderungen. Dann sollte es
reichen, die Änderungen aus dem Weg zu räumen, 'git checkout $neues_tag'
zu machen, und die Änderungen fallweise wieder einzuspielen.

Ich sage bewusst "Änderungen aus dem Weg räumen" statt einfach 'git
stash', weil 'git stash' neu erzeugte Dateien dalässt.

Wenn ich vor einem solchen Problem stehe, erzeuge ich einen Commit aus
den Dateien ('git add .', 'git commit'), merke mir die Commit-ID, gehe
auf den Zielbranch, und cherry-picke die Commit-ID. Das ist quasi
rebase, händisch ausgeführt. Es ist aber kein magischer Weg, die
Merge-Konflikte zu beseitigen.

Post by Marc Haber

Post by Stefan Reuther
Ansonsten klingt das, als ob du
git rebase --onto v2.4 v2.3.5 prod
suchst ("nimm die Änderungen von v2.3.5 -> prod und appliziere die auf
v2.4").

Mit committeten oder gestashten Änderungen?

Vor rebase muss der Workspace immer sauber sein.

Post by Marc Haber

Post by Stefan Reuther

Post by Marc Haber
Auch "git checkout prod", "git merge v2.4" endet in einer laaaaangen
Liste von Mergekonflikten.

Da wäre die Frage, wie die History wirklich aussieht.

Magst ein tar.gz vom Repository?

Wenn es sich um die Blogsoftware mit dem komischen Namen handelt, find
ich die bei github. Dann seh ich dort auch, dass der Branch "2.3"
ziemlich lange parallel zum master existierte. Damit ist "v2.4" kein
direkter Nachfolger von "v2.3.5".

Post by Marc Haber

Post by Stefan Reuther
Wenn der master eine lineare History von v2.3.5 ... v2.4 hat, sollte das
völlig schmerzfrei sogar als fast-forward merge gehen. Wenn die v2.3.5
aber bereits ein Branch ist, der z.B. rückportierte Fixes aus dem master
erhalten hat, bekommst du damit natürlich Konflikte (Bugfix auf master
vs. rückportierter Fix auf Release).

Sollte git nicht erkennen dass da ein Commit schon angewendet wurde?

Wenn die Commits halbwegs identisch sind, ja. Wenn da rückportierte
Fixes textuell anderen Inhalts drin sind, möglicherweise nicht.
Beispiel: Fehler in der Interaktion mit einer veralteten Komponente.
Lösung im Unstable-Zweig: Unterstützung dafür ausbauen, soll halt
updaten. Lösung im Stable-Zweig: Workaround einbauen. Das kriegt kein
SCM der Welt je gemerged.

Post by Marc Haber
Wie krieg ich am einfachsten raus ob es eine lineare History gibt?
Kann mir git merge-base da helfen, z.B. wenn 2.3.5 eine merge base von
2.3.5 und 2.4 ist?

Ich hab mich jetzt durch die grafische Ansicht im Github gewühlt (ist
die wirklich so scheixe? Endlich mal was, was gitlab besser macht.)

Ansonsten kannst du 'git log --graph v2.3.5 v2.4' machen und schauen,
was rauskommt.

Post by Marc Haber

Post by Stefan Reuther
git checkout anderer-branch -- $(git diff --name-only
alte-version-vom-anderen-branch anderer-branch)
Das vernichtet halt ggf. deine Änderungen, weswegen ich schon irgendwie
verstehen kann, dass man das nicht *zu* einfach macht.

Die könnte man sich ja vorher sichern wenn man wüsste um welche es
geht.

...und das kriegt man halt mit einem Kommando wie 'git diff --name-only'
raus.

git diff $(git diff --name-only alte-version neue-version)

---> welche Änderungen habe ich in Dateien durchgeführt, die sich
zwischen alter und neuer Version geändert haben?


Stefan

[Marc Haber]

Post by Marc Haber
ich habe hier die folgende Situation: Gegeben sei eine Webapplikation
S, die von ihren Autoren bevorzugt als git Repository released wird.

Nach fast einem jahr ist mir jetzt der Kragen geplatzt und ich update
jetzt (wieder) aus den zip-Dateien, die mit dem Release veröffentlicht
werden. Das Verfahren mit git werde ich nie verstehen.

Grüße
Marc