Lokale git branches

    Hallo,


    inspiriert durch den anderen git-thread (der hat mich sehr neugierig gemacht - git book liegt auf einem usb-stick jetzt immer unter meinem Kopfkissen... ;) bin leider noch nicht über Kapitel 3 hinaus), frage ich mich folgendes:


    Ich habe im Moment drei vdr-1.7.33 inkl. Plugin-Zweigen:


    1. original ungepatcht
    2. mit angepassten Patches (mit yarpg-hack und softhddevice und skinnopacity mit yaepg-scaling)
    3. mit einigen yavdr-Patches (mit softhddevice und skinnopacity mit neuem Scaling)


    Da müßte man doch sehr sinnvoll mit lokalen branches arbeiten können. Da jetzt aber durch den Plugin-Zweig im VDR noch andre gits dazu kommen, sehe ich gerade den Wald vor lauter Bäumen nicht.


    Kann ich in dem "reinen" vdr einfach ein git init machen, dann git add ., dann den 2.Zweig drüber kopieren und git add branch yaepg-hack, dann den 3. Zweigbdrüber kopieren und analog zu yaepg-hack ein new-scaling anlegen. um dann immer master, yaepg-hack oder news-scaling auszuchecken?


    Und wie mache ivh es, dass wenn ich ein Plugin update es in allen branches geupdated wird? Bzw. z.B. für softhddevice und skinopacity eben NICHT in allen Branches geupdatet wird? Wie kann ich dan ein diff zwischen den Branches sehen?


    Ihrt srht, ich bin git-mäßig gerade mit gefährlichem halbwissen unterwegs...


    Gruß, Ingo

    Moin!


    Ich kann ja einfach mal meine Entwicklungsumgebung beschreiben, vielleicht beantwortet es ein wenig deine Fragen... :)


    Ich hab ein vdr-git-Repository mit dem vanilla-vdr im upstream-Branch (Code ist nur skizziert, sitze gerade nicht am Linux-Rechner):

    Code
    mkdir ~/src/vdr
cd ~/src/vdr
git init
git-import-orig --pristine-tar ../vdr-1.7.33.tar.bz


    Im Verzeichnis PLUGINS/src habe ich für jedes Plugin (ausgenommen die, die mit dem vdr mitgeliefert werden) ein eigenes git-Repository:

    Code
    cd ~/src/vdr/PLUGINS/src
git clone -o upstream git://github.com/flensrocker/vdr-plugin-dbus2vdr.git dbus2vdr
git clone -o upstream git://github.com/flensrocker/vdr-plugin-dynamite.git dynamite
(oder auch mit git-import-orig, falls es kein upstream-git gibt)


    Bei meinen eigenen Plugins lasse ich den Namen des git-remote allerdings bei "origin", da ich auf meinen git-Repositories ja push-Rechte habe.


    Da dynamite einen Patch benötigt, erstelle ich für die Entwicklung des Patches einen eigenen Branch aus dem vanilla-vdr:

    Code
    cd ~/src/vdr
git checkout -b dynamite master
(Patch entwickeln und fleißig committen)


    Um das alles zu testen, benutze ich ganz einfach "make all plugins", dazu noch ein kleines Script, was den vdr mit den für mich relevanten Parametern startet. Das liegt außerhalb dieses Verzeichnisbaums in ~/src.


    Wenn der Patch "fertig" ist, dann erstelle ich ihn so:

    Code
    git diff master dynamite > PLUGINS/src/dynamite/patches/vdr-1.7.33-dynamite.patch


    Und checke ihn im entsprechenden Plugin-Verzeichnis ein. (vielleicht muss es auch "git diff dynamite master" heißen, das kann ich mir nicht merken, dazu schaue ich mir immer die Ausgabe an, ob der Patch richtig herum aussieht :))


    Da ich das ganze für yaVDR, sprich Ubuntu/Debian mache, will ich auch noch die anderen Patche verwalten (noch Zukunft, ich lerne ja gerade):

    Code
    cd ~/src/vdr
git checkout -b dynamite master
(debian-Verzeichnis mit Patches anlegen, die Patches dazu aus dem Plugin-Sourcen holen)
git add debian
git commit -m "add debian"
gbp-pq import


    Jetzt habe ich zusätzlich einen Branch "patch-queue/master", in dem die einzelnen quilt-Patches als einzelne Commits in der Reihenfolge der series-Datei liegen.
    Dort bearbeite ich die Patches, so dass sie zusammenpassen:

    Code
    git checkout patch-queue/master
git log
(passende commit-id heraussuchen)
git checkout <commit-id>
(editieren, testen usw.)
git add ... ; git commit ...


    Dann mit einem "git rebase -i" irgendwie die einzelnen Commits wieder so zusammenführen, dass da die einzelnen Patches daraus entstehen. Das ist noch etwas ungenau in meinem Kopf, da brauche ich eine Shell zu, um das zu dokumentieren...


    Übernahme der Patches ins debian-Verzeichnis:

    Code
    git checkout master
gbp-pq export
git add debian
git commit


    Das kann man aber auch mit quilt auf dem master-Branch machen, das ist Geschmackssache. Was mich momentan hieran noch stört, ist, dass die Kommentare aus den series und patch-Dateien rausfliegen. Die müsste ich dann wohl in einer eigenen Datei verwalten, will mir das aber noch nicht antun.


    Und wenn ich im master-Branch dann mal wieder einen Stand habe, der für den Dauertest installiert werden soll, passe ich das changelog an und baue ein Paket mit git-buildpackage.


    Mit "git checkout" kannst du nun fröhlich zwischen den verschiedenen vdr-Versionen hin und her wechseln, sogar auch zu älteren Versionen, wenn du sie im git hast.
    Manchmal muss man dann aber mal "make clean clean-plugins" vor dem "make all plugins" aufrufen, um mal wieder ein sauberes Compilat zu bekommen.
    Was noch ein wenig "aufwendig" ist, ist das einzelne Wechseln der Unter-Repositories (die Plugins), wenn man da auch noch verschiedene Stände hat. Aber ich behelfe mir da mit mehreren Shells, jeweils im passenden Verzeichnis. Und meistens arbeite ich nur an einer Baustelle zur Zeit... :)


    Lars.

    Ja, das ich fange an zu verstehen...Ich muss ds einfach mal ausprobieren und noch ein paar Kapitel lesen - dann fallen mir bestimmt neu Fragen ein. ;) Danke.


    Gruß, Ingo

    Hallo,


    ich habe natürlich nicht im git book weiter gelesen, sondern habe ersteinmal das Spielen begonnen. Ich beschreibe das hier mal - evtl. ist es ja für den ein oder andern hilfreich. Ansonsten ist es für den git-Kenner zumindest amüsant... Ich kratze im Moment nur an der Oberfläche von git, aber es tut hier so, wei es soll.


    Lars: git-import-orig habe ich natürlich nicht auf gentoo, das gehört alles in buildpackage. Macht aber nix. Ich habe die nicht-GIT-Plugins einfach so übernommen, und wenn ich an einem solchen Plugin etwas ändern will, müßte das hier auch tun:

    Code
    cd PLUGINDIR
git init
git add .
git commit -m "making a local Fake-Git initial commit"
git checkout -b my_PLUGIN
[ganz viele Dateien editieren und anlegen]
git add [neu angelegte Dateien]
git add -u
git commit -m "My new code"


    Aber der Reihe nach:


    Ich habe einfach das vdr-git (noch 1.7.32) geclont und auf 1.7.33 gepatcht. Dann habe ich die von mir benutzten Plugins (sowohl git, als auch die Statischen), in den VDR-Tree kopiert. In .gitignore nehme ich alle Plugins, die nicht direkt von kls stammen aus, genauso wie *.o *.so und noch ein paar Sachen:

    Code
    cat /etc/gitconfig
.gitignore
*.o
*.so
po/*.mo
po/*.pot
PLUGINS/lib
PLUGINS/src/[plugin-dirs]


    Im Netz habe ich mir noch zwei IMHO sinvolle aliases geklaut:

    Code
    [user]
        name = ingo
        email = xxxxxxxx


[alias]
        lg1 = log --graph --all --format=format:'%C(bold blue)%h%C(reset) - %C(bold green)(%ar)%C(reset) %C(white)%s%C(reset) %C(bold white)— %an%C(reset)%C(bold yellow)%d%C(reset)' --abbrev-commit --date=relative
        lg2 = log --graph --all --format=format:'%C(bold blue)%h%C(reset) - %C(bold cyan)%aD%C(reset) %C(bold green)(%ar)%C(reset)%C(bold yellow)%d%C(reset)%n''          %C(white)%s%C(reset) %C(bold white)— %an%C(reset)' --abbrev-commit
lg = !"git lg1"


    In meinem vdr-git habe ich jetzt das lustige Branchen (nach dem sonntäglichen Brunchen) angefangen, und in den branches das lustige Patchen. Ich habe jetzt die Branches

    Code
    git branch
  g2v-extp
  master
  my_vdr
  my_vdr_my_patches
* my_vdr_yavdr


    g2v-extp ist noch 1.7.32. my_vdr hat gegenüber master nur meine angepasste Make.config und ein script (rebuild.sh). my_vdr_my_patches und my_vdr_yavdr sind geclont von my_vdr:


    So ähnlich habe ich das auch bei softhddevice und skinnopacity gemacht:

    Code
    softhddevice $ git lg1
* 714cdbd - (50 minutes ago) Lucians new_scaling v3: 0001-softhddevice-video-scaling-without-YAEPG-vdr-1.7.33-v3.diff — ingo (new_scaling_v3)
| * eea9730 - (19 hours ago) aplied softhddevice-video-scaling-without-YAEPG-vdr-1.7.33.diff — Ingo Prochaska (new_scaling)
| * c7982f4 - (19 hours ago) initial new_scaling — Ingo Prochaska
|/
* 943ee22 - (3 days ago) Makes X11 server arguments configurable. — Johns (HEAD, origin/master, origin/HEAD, master)

    und

    Code
    skinnopacity $ git lg1
* faac79a - (32 minutes ago) new_scaling_v3 applied 0001-nopacity-video-scaling-without-YAEPG-vdr-1.7.33-v3.diff from Lucian — ingo (HEAD, my_skinnopacity_new_scaling_v3)
* c3e5f78 - (39 minutes ago) Show Enigma.jpg in Recordings Info Text — ingo (my_skinnopacity)
* e149ae4 - (42 minutes ago) Enlarged Symbols in Channel Display — ingo
| * 199e172 - (15 hours ago) applied patches/nopacity-video-scaling-without-YAEPG-vdr-1.7.33.diff from Lucian — Ingo Prochaska (new_scaling)
|/
* ec274fc - (23 hours ago) Whitespace Cleanup — louis (origin/master, origin/HEAD, master)


    Soweit war das erstmal etwas Arbeit, andereseits verführt git dazu, seine Arbeit zumindest rudimentär zu dokumentieren: wenn man sich von Anfang an zwingt, jede Änderung (Patch) auch zu commiten, ist es viel leichter nicht in den Kopfstatus "lost in patch" zu wechseln... ;) Jetzt ist es natürlich sehr einfach, verschieden Kombinationen zu Testen.


    Z.B.: Ich möchte "meinen" vdr mit der neuen (v3) Version des neue Scalings testen (benötigt Patche in sofhddevice und skinnopacity):

    Wenn ich jetzt gleich meine scr-Installation (mein diodenentkoppleter 4-fach-Verteiler mit dc-Durchlass von allen Ausgängen ist gerade gekommen) testen möchte, will ich natürlich mit einen "unversauten" vdr testen:

    In drei Tagen werde ich mich nicht mehr daran erinnern, warum mein master 3 commits voraus ist, und ich werde mich fragen: Mist, ist das jetzt auch wirklich ein "reiner" vdr?

    Aha, alles gut.


    Ich hoffe man ließt meine Begeisterung für dieses Tool durch, nochmal vielen Dank an goldbär und Lars fürs neugierig Machen und Inspirieren...


    Gruß, Ingo

    Moin!


    Zitat von nvertigo

    In .gitignore nehme ich alle Plugins, die nicht direkt von kls stammen aus, genauso wie *.o *.so und noch ein paar Sachen:


    Klar, so eine Datei hab ich auch, macht alles übersichtlicher beim "git status".


    Zitat von nvertigo

    Im Netz habe ich mir noch zwei IMHO sinvolle aliases geklaut:


    Muss ich mir mal ansehen, klingt interessant. Momentan komme ich noch mit dem normalen "git log" zurecht, aber etwas mehr Übersicht ist nie verkehrt.


    Zitat von nvertigo

    In drei Tagen werde ich mich nicht mehr daran erinnern, warum mein master 3 commits voraus ist


    Für meinen Geschmack haben diese commits da nichts zu suchen. :) Wenn das das upstream sein soll, dann darf da auch nichts anderes sein. Spätestens bei den nächsten upstream-Commits, die du ziehst, wirst du Merge-Konflikte bekommen, die dann wieder aufgelöst werden müssen. Ich finde es wichtig, einen eigenen, sauberen Branch zu haben, in dem die Original-Upstream-Quellen sind.
    Ich hätte deine Commits in einem eigenen Branch "hotfixes" oder so angelegt, und den dann in my_vdr gemergt. Wenn es dann was neues upstream gibt, müsste man dann nur mit einem "git rebase -i" den Abzweiger von my_vdr wieder auf master umbiegen. Da braucht man dann nur die hotfix-Commits rausnehmen (zumindest die, die upstream in irgend einer Art eingeflossen sind) und alles ist ok.
    Aber ernsthaft ausprobiert hab ich das jetzt auch nicht, auch bei meiner Variante kann es Probleme geben.


    Zitat von nvertigo

    Ich hoffe man ließt meine Begeisterung für dieses Tool durch, nochmal vielen Dank an goldbär und Lars fürs neugierig Machen und Inspirieren...


    Wenn man sich erst mal darauf eingelassen hat, ist das wirklich cool, das Ding. Ich komme von cvs über Subversion und Mercurial (auf Arbeit) und bin privat jetzt bei git gelandet, weil ich mich da am wohlsten fühle.


    Lars.

    Zitat von mini73


    Für meinen Geschmack haben diese commits da nichts zu suchen. :) Wenn das das upstream sein soll, dann darf da auch nichts anderes sein. Spätestens bei den nächsten upstream-Commits, die du ziehst, wirst du Merge-Konflikte bekommen, die dann wieder aufgelöst werden müssen. Ich finde es wichtig, einen eigenen, sauberen Branch zu haben, in dem die Original-Upstream-Quellen sind.
    Ich hätte deine Commits in einem eigenen Branch "hotfixes" oder so angelegt, und den dann in my_vdr gemergt. Wenn es dann was neues upstream gibt, müsste man dann nur mit einem "git rebase -i" den Abzweiger von my_vdr wieder auf master umbiegen. Da braucht man dann nur die hotfix-Commits rausnehmen (zumindest die, die upstream in irgend einer Art eingeflossen sind) und alles ist ok.
    Aber ernsthaft ausprobiert hab ich das jetzt auch nicht, auch bei meiner Variante kann es Probleme geben.


    OK. Da hast Du recht. Bei dem 1.7.32-1.7.33.diff kann man natürlich drüber streiten, ob dass hotfix ist - weil es ja mit Sicherheit im Upstream kommen wird -, oder ob das master ist, weil nur jemand es (noch) nicht auf vdr-developrs gepusht hat... Wenn das git irgendwann in der Zukunft dann mal ein Update auf 1.7.34 bekommt, könnte man ja auch mit reset --hard auf den 1.7.32 TAG als HEAD zurück, dann pullen und dann mit entsprechenden skips rebasen (rebase finde ich geil - hab heimlich weiter gelesen ;) ).


    Ich habe aber ein anderes systematische Problem (glaube ich zumindest): Meine Repositorys sind ja geklont. Jetzt dachte ich, das ich lokal master habe und dann eben origin/master im git auf vdr-developers. Jetzt habe ich aber beim skinnopacity gestern bemerkt, dass es scheinbar nur noch das lokale gibt: wenn ich z.B. ein "git diff origin/master" gemacht habe, habe ich immer nur ein diff gegen mein lokales master bekommen. Auch ein "git diff master origin/master" war leer. Gibt es eine Möglichtkeit, das anders einzubinden? Sollte man nicht auch bei einem "git status" in master einen Hinweis bekommen, dass origen/master schon weiter ist?


    Gruß, Ingo

    Moin!


    Hinweis zum geilen rebase: Wenn man sich ein remote-Repository mit anderen Leuten teilt, ist rebase "verboten", da es die geklonten Repositories der Mitstreiter durcheinanderbringen kann.
    Aber um lokale Branches aufzuräumen, damit sie für upstream gut in Schuss sind, ist es genau das richtige Werkzeug. :)


    Zum "git diff":
    Bei mir klappt alles... :) Wie sieht .git/config aus, was sagt "git log"? Wo laufen master und origin/master auseinander?


    Ich versuche immer, fremde Repositories als "upstream" einzubinden:

    Code
    mkdir <name>
cd <name>
git init
git remote add upstream <url>
git fetch --all
git checkout --no-track -b master upstream/master


    Wichtig ist der Unterschied zwischen "fetch" und "pull". Denn ein "pull" macht gleichzeitig auch ein "merge". Meistens will man das, man sollte sich dessen nur bewusst sein.
    Durch das "--no-track" wird das lokale master nicht mit dem upstream/master verbunden, so dass ein "push" in master nicht weiß, wohin er soll. In upstream hat man ja meistens kein push-Recht, deshalb ist das sinnvoll.
    Sollte man später doch mal push-Rechte bekommen, kann man eine Verbindung immer noch herstellen:

    Code
    git push -u master upstream/master


    Meistens erstelle ich mir bei github.com o.ä. Hostern ein eigenes Remote-Repository als Online-Backup. Das binde ich dann als "origin" ein, da ich dort ja push-Rechte habe.

    Code
    git remote add origin <url>
git fetch --all
git push -u master origin/master


    Auch ohne ein Tracking herzustellen kann man in ein Remote-Repositories pushen:

    Code
    git push master upstream/master


    Eine Besonderheit bei mir ist z.B., dass ich im yavdr-Account ein git-Repository hab, wo im master das debian-Verzeichnis habe, während mein remote-master natürlich "vanilla" ist. Ich habe also zwei Repositories mit push-Rechten. Bin ich in meinem master fertig und möchte die Änderungen nach yavdr übernehmen, möchte ich yavdr/master auschecken, aber nicht mit meinem master verbinden. Ist ja kein Problem, ich kann lokal ja auch einen anderen Branchnamen benutzen. Dann muss man nur beim Pushen aufpassen:

    Code
    git clone <meine-url> <name>
cd <name>
git remote add yavdr <yavdr-url>
git fetch --all
git checkout -b yavdr_master yavdr/master
git merge master
git push -u yavdr yavdr_master:master


    Mit dieser Doppelpunkt-Geschichte kann ich einen lokalen Branchnamen auf einen Remote-Branch mappen.


    Lars.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden