yaVDR ansible - Änderungen im lokalen GIT wie erhalten ...

  • Hallo!


    Trotz der tollen Arbeit von Seahawk und der Möglichkeit fast alles in der eigenen host_vars/localhost zu customizen, muss ich zwei Dateien manipulieren, um unser yaVDR-Erlebnis perfekt zu machen:


    In roles/yavdr-remote/templates/rc_maps.cfg.j2 benutzen wir für "nuvoton-cir" unsere eigene Keymap (mit unserer seit Jahren gewohnten Tastenbelegung)

    In roles/yavdr-desktop/templates/.lircrc.j2 haben wir einen anderen Button als Kodi-Taste definiert (KEY_PROG2 statt KEY_HOME)


    Statt regelmässigem update & dist-upgrade wird seit Ubuntu 18 (und Ansible) eigentlich immer eine Installation mittels sudo -H ./install-yavdr.sh durchgeführt.


    Da laufend Verbesserungen in Seahawks GIT gemacht werden, möchte ich dafür immer seinen aktuellste Stand benutzen, angereichert um meine lokalen Einstellungen (host_vars/localhost) und meine "Manipulationen".


    Ich habe einiges über GIT gelesen und vieles ausprobiert und bin dann immer wieder da gelandet, dass ich meine lokale Kopie komplett gelöscht und yavdr-ansible neu geladen habe.

    Natürlich musste ich dann alle meine Änderungen immer wieder einpflegen, um schlußendlich das install-Skript ausführen zu können. :thumbdown:


    Ich möchte immer den aktuellsten Ansible-Stand vom Github, aber meine Änderungen sollen trotzdem erhalten bleiben - zumindest solange sich diese konkreten Dateien nicht komplett geändert haben.



    Wie geht das bitteschön "in schön"?

    MyVDR (Hardwareliste) : yaVDR 0.6 - softhddevice-openglosd - epgd/epg2vdr - skindesigner estuary4vdr (adaptiert) - 1920x1080@50 Hz | kodi 17.1 - inputstream - amazon prime vod *broken*
    Aerocube M40 | 300W | ASRock H61M-GE | Intel G530 | Asus ENGT520 | 2 x TT-budget S2-3200 | ASRock Smart Remote (CIR) | 4 GB RAM | 3 TB HDD

    The post was edited 1 time, last by davie2000 ().

  • Danke für deine Antwort!


    Ja, so habe ich das auch schon zig-mal gemacht und trotzdem endete ich am Schluss immer mit Löschen und Neuanfangen.

    Weil beim PULL - trotz eindeutiger Änderungen im Browser auf github - sich nichts geändert hat, habe ich dann meist zum Zaubern begonnen und mir alles zerschossen, sodass ich von vorne angefangen habe.

    Aber wenn der Weg eigentlich der richtige wäre, werde ich so weitermachen und mich vor dem nächsten Zaubern hier wieder melden.


    Wenn wir schon so schön dabei sind:

    Wie handelst du Änderungen/Neuerungen in der group_vars/all elegant - da sich diese ja nicht automatisch in der lokale Kopie (host_vars/localhost) niederschlagen?

    MyVDR (Hardwareliste) : yaVDR 0.6 - softhddevice-openglosd - epgd/epg2vdr - skindesigner estuary4vdr (adaptiert) - 1920x1080@50 Hz | kodi 17.1 - inputstream - amazon prime vod *broken*
    Aerocube M40 | 300W | ASRock H61M-GE | Intel G530 | Asus ENGT520 | 2 x TT-budget S2-3200 | ASRock Smart Remote (CIR) | 4 GB RAM | 3 TB HDD

  • Ja, so habe ich das auch schon zig-mal gemacht und trotzdem endete ich am Schluss immer mit Löschen und Neuanfangen.

    Weil beim PULL - trotz eindeutiger Änderungen im Browser auf github - sich nichts geändert hat, habe ich dann meist zum Zaubern begonnen und mir alles zerschossen, sodass ich von vorne angefangen habe.

    Klingt so, als ob du Git Branches und das Auflösen von Merge-Konflikten noch nicht ganz beherrschst. Ich muss mal schauen, ob mir da was gutes einfällt, wie man das Vorgehen nachvollziehbar zeigen kann.

    Wie handelst du Änderungen/Neuerungen in der group_vars/all elegant - da sich diese ja nicht automatisch in der lokale Kopie (host_vars/localhost) niederschlagen?

    Wenn man Variablen in der host_vars/localhost definiert, überlagert das die Variablen aus der group_vars/all - wenn etwas in der group_vars/all dazu kommt, sollte das eigentlich nicht stören (man muss nur bei verschachtelten Variablenstrukturen aufpassen, die Werte darin werden nicht zusammengeführt).

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Hallo,


    Ich würde hier an Deiner stelle mit zwei branches arbeiten. Hierzu einfach als erstes seahawks git repository clonen:

    git clone <repo url>

    Danach erstellst Du Deinen eigenen Branch zum arbeiten, mit dem aktuellen Stand:

    git checkout -b <branch name>

    Jetzt hast Du zwei branches, master ist die Kopie von Seahawk, <branch name> Deiner, auf dem gleichen Stand wie master.

    Du kannst nun Deine Änderungen durchführen und die Änderungen kommitten

    Mit git status siehst Du, welche Dateien geändert wurden

    Mit git add . fügst Du alle geänderten Dateien zum Commit hinzu, bzw. mit git add <filename> einzelne files hinzu.

    Als letztes ein git commit erstellst Du Dir den commit.

    Wenn es nun Änderungen bei seahawks git gibt, wechselst du zum master branch mit git checkout master und holst Dir alle Änderungen mit git pull. Nun mit git checkout <branch name> und jetzt kann man in den meisten Fällen mit git rebase master alle Änderungen aus master einspielen. Hierbei wird Dein Commit im Prinzip zurückgerollt, alle neuen Änderungen aus master übernommen und anschließend Dein Commit on top eingespielt.

    Es gibt aber auch die Möglichkeit, anstatt dem Rebase ein Merge durchzuführen, hierzu statt dem rebase Kommando eben git merge master ausführen.

    Einen wirklichen Unterschied it’d es bei Dir eher nicht geben, wobei die History meiner Meinung beim rebase schöner ist. Deine Änderung ist dann nämlich immer die Letzte.


    Zumindest bei mir in der Firma hat sich dieses Vorgehen bewährt.


    Gruß Doc_hollywood

    Current:

    Hardware_: Gigabyte B360M D3H, Silverstone Milo ML03, DD Cine S2 V7A, 256GB Samsung EVO 970, 4GB RAM, ASUS GT1030 passive

    Software_: ArchLinux, VDR4Arch, VDR 2.4.0, softhdcuvid, nordlichtsepg, skinenigmang


  • Mit git add . fügst Du alle geänderten Dateien zum Commit hinzu,


    "git add ." fügt alle Dateien hinzu. Nicht nur geänderte.

    Ich konnte auf die Schnelle auch nichts finden was explizit alle geänderten Dateien hinzufügt. Am ehesten vielleicht "git add -u"


    "git commit -a" committed alle geänderten Dateien ohne das man "git add" braucht.

  • git add -u ist mein bevorzugtes Kommando, um Änderungen zum nächsten Commit hinzuzufügen.


    Und statt rebase würde ich immer merge benutzen, denn dann kann man sein git auch irgendwo hinpushen und auf anderen Rechnern klonen. Bei einem Rebase ist ein Pull immer etwas doof.


    Letztlich darf aber jeder in seinem Repository machen, was er möchte.

  • So ist es. Und git bietet so viele Möglichkeiten, dass es den einen "richtigen" Weg nicht gibt. Jeder bevorzugt eine andere Arbeitsweise.


    Mit "Branches" bin ich z.B. selber nie so richtig warm geworden. Ich nutze die schon mal um zeitweise einen zweiten Arbeitsstand parallel zu führen (z.B. um eine alternative Herangehensweise an ein Problem dort zu verwalten) aber Branches haben bei mir immer zum Ziel irgendwann wieder auf "master" gemerget und dann gelöscht zu werden.


    Wenn ein Repo, das man lokal leicht ändern will, bei Github steht, dann wäre auch möglich erstmal auf den eigenen Account einen Fork zu machen. Dann den auschecken und das Original als zusätzliches "remote" dazu. Ich nenne das Original dann immer "upstream".


    So kann man im eigenen Repo nicht nur committen sondern auch zum Server pushen (als Backup oder um den Stand auf verschiedenen Rechnern synchron zu halten). Um Änderungen vom Original-Repository zu bekommen reicht dann ein gelegentliches "git pull upstream master".

  • Jupp, so mache ich das auch, wenn ich einen Patch für ein Projekt entwickle (und ist nicht an GitHub gebunden). Man kann genauso von GitHub etwas klonen und es dann nach GitLab oder anderen Hoster pushen.


    Zwei remotes sind aber im Prinzip auch einfach nur zwei Branches.

  • Nur als kleine Eränzung zu der Anleitung von Doc_Hollywood : der Branch für Ubuntu 18.04 heißt bei yavdr-ansible bionic (master habe ich aber gerade auf den selben Stand gebracht).

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Wow ... vielen Dank für die zahlreichen guten Antworten!


    Ich werde mich wohl die Tage mal hinsetzen und das komplett neu - aber richtig - aufziehen.

    Hoffentlich werden dann auch ALLE Dateien in der neuesten Version installiert (siehe hier).

    MyVDR (Hardwareliste) : yaVDR 0.6 - softhddevice-openglosd - epgd/epg2vdr - skindesigner estuary4vdr (adaptiert) - 1920x1080@50 Hz | kodi 17.1 - inputstream - amazon prime vod *broken*
    Aerocube M40 | 300W | ASRock H61M-GE | Intel G530 | Asus ENGT520 | 2 x TT-budget S2-3200 | ASRock Smart Remote (CIR) | 4 GB RAM | 3 TB HDD

  • "git add ." fügt alle Dateien hinzu. Nicht nur geänderte.

    Klar, es werden neben geänderten auch neue bzw. gelöschte Dateien hinzugefügt (verschobene genauso). Aber keine, bei denen nichts passiert ist.

    Für den beschriebenen Fall geht es aber eigentlich nur um eine Änderung ;)


    Aber in der Tat gibt es viele verschiedene Wege. Das mit „upstream“ verwende ich in der Tat genauso, wollte aber die Anleitung einfach halten.

    Nur als kleine Eränzung zu der Anleitung von Doc_Hollywood : der Branch für Ubuntu 18.04 heißt bei yavdr-ansible bionic (master habe ich aber gerade auf den selben Stand gebracht).

    Zugegebenermaßen habe ich mir Dein Repository gar nicht angeschaut :)


    Gruß Doc_Hollywood

    Current:

    Hardware_: Gigabyte B360M D3H, Silverstone Milo ML03, DD Cine S2 V7A, 256GB Samsung EVO 970, 4GB RAM, ASUS GT1030 passive

    Software_: ArchLinux, VDR4Arch, VDR 2.4.0, softhdcuvid, nordlichtsepg, skinenigmang


  • Wenn man Variablen in der host_vars/localhost definiert, überlagert das die Variablen aus der group_vars/all - wenn etwas in der group_vars/all dazu kommt, sollte das eigentlich nicht stören (man muss nur bei verschachtelten Variablenstrukturen aufpassen, die Werte darin werden nicht zusammengeführt).

    Stören tuts mich eh nicht ;-)

    Aber ich würde gerne deine aktuellsten Änderungen (Verbesserungen) mitbekommen und das geht meines Wissens nach nur mit manuellem diff und da übersehe ich deine Änderungen leicht, weil mein Customizing natürlich als (sehr) viele Änderungen angezeigt wird. Aber bis jetzt habe ich - hoffentlich - alle Verbesserungen mitbekommen.

    Wie zB letztens die Möglichkeit, das Ent-/Laden der DVB-Treiber customizable zu machen :tup


    Edit:

    Wenn es nun Änderungen bei seahawks git gibt, wechselst du zum master branch mit git checkout master und holst Dir alle Änderungen mit git pull.

    Das hatte ich mehrmals so gemacht, aber es sind nie alle Änderungen (lt. Historie auf github im Browser) in meinen lokalen Dateien angekommen. Und gelöschte Dateien wurden nicht wieder neu geholt.


    Aber ich bin gerade dabei das mit meinem eigenen Branch und merge (statt rebase) zu probieren. Sollte ich damit nicht das Auslangen finden, werde ich mich an der "upstream"-Methode versuchen.


    Edit 2:

    Ich hab jetzt einen eigenen branch "myvdr" eröffnet und dort meine Änderungen gemacht und schöne einzeln commited.

    Dann habe ich das Install-Skript laufen lassen und updates wurden durchgeführt - soweit alles prima - Danke euch!

    Jetzt warte ich gespannt auf die nächste Änderung von Seahawk und werde dann mal schauen obs mit pull und merge dann auch wirklich funktioniert ...

    MyVDR (Hardwareliste) : yaVDR 0.6 - softhddevice-openglosd - epgd/epg2vdr - skindesigner estuary4vdr (adaptiert) - 1920x1080@50 Hz | kodi 17.1 - inputstream - amazon prime vod *broken*
    Aerocube M40 | 300W | ASRock H61M-GE | Intel G530 | Asus ENGT520 | 2 x TT-budget S2-3200 | ASRock Smart Remote (CIR) | 4 GB RAM | 3 TB HDD

    The post was edited 4 times, last by davie2000 ().