git-buildpackage: Grundsätzliche Fragen

  • Hallo,


    ich habe ein paar grundsätzliche Verständnisfragen zu git-buildpackage.
    Evtl. kann mir ja einer von euch dabei etwas helfen.


    Ich möchte lerner selbst Pakete für mich zu erstellen. Diese Pakete will ich nirgends veröffentlichen.
    Da ich auch gerne am VDR herumbastel, liegt es nahe es am Beispiel der VDR-Pakete zu lernen.


    1. tar-Ball
    git-buildpackage will immer einen passenden tar-Ball zu den Upstream-Sourcen.
    Ich hole mit die Sourcen immer mit "git clone/pull".
    Dann hat man aber keinen tar-Ball.
    Man könnte sich natürlich zusätzlich den tar-Ball mit wget holen oder ihn selbst mit tar erzeugen. Aber das scheint mir nicht der richtige Weg zu sein.
    Wie macht ihr das?


    2. upstream Branch
    In jeder Doku, die ich zu git-buildpacke gefunden habe, liegen die Sourcen im Branch upstream und das debian-Verzeichnis mit allen Änderungen im Branch master.
    Nach "git clone" gibt es aber nur den Branch master.
    Wie macht ihr das?



    Grundsätzlich gehe ich folgendermaßen vor:


    git clone git://...<paket>.git
    cd <paket>


    mkdir debian
    Notwendige Dateien im debian-Verzeichnis erzeugen (evtl. auch mit dh_make)


    git add debian/
    git commit -m "added debian"


    Evtl. Patches mit quilt erstellen


    git-buildpackage -us -uc



    Dann habe ich die oben beschriebenen Probleme.


    Ist mein Vorgehen falsch/ungeschickt?

    HW: Gigabyte EP41-UD3L | Core2Duo 7400 | 2GB Kingston | MSI N220GT-MD1GZ (passiv) | L4M-Twin S2 ver 6.5 mit Flex S2 | Silverstone LC16M mit iMON VFD | Samsung LE46B750
    SW: Xubuntu 14.04 3.13.0-24 | NVIDIA 304.117 | vdr 2.1.6 | softhddevice | inputlirc | lcdproc

  • Moin!


    Ich benutze git-buildpackage (noch) nicht, aber...


    2. upstream Branch
    In jeder Doku, die ich zu git-buildpacke gefunden habe, liegen die Sourcen im Branch upstream und das debian-Verzeichnis mit allen Änderungen im Branch master.
    Nach "git clone" gibt es aber nur den Branch master.
    Wie macht ihr das?


    Code
    mkdir <name>
    cd <name>
    git init
    git remote add upstream <url>
    git fetch --all
    git checkout -b upstream/master master
    mkdir debian
    (Dateien anlegen)
    git add debian
    git commit


    Der Clou ist, zuerst ein leeres git-Repository anzulegen und dort das upstream-Repository einzubinden.


    Kommt dann ein Update im upstream-Repository (ungetestet, hab gerade nichts verfügbar):

    Code
    git fetch --all
    git merge upstream/master master


    Lars.

  • Hallo mini73,


    so wie du das machst gibt es doch lokal bei dir auch nur einen Branch master. Oder verstehe ich das falsch?
    git-buildpackage geht aber davon aus, dass man zwei getrennte Branches hat.
    1. Upstream-Branch für die Upstream-Sourcen (Default-Name ist upstream)
    2. Debian-Branch für das Debian-Verzeichnis mit den notwendigen Dateien und Patches (Default-Name ist master).
    Geändert wird nur im Debian-Branch



    Ich habe jetzt mal etwas herumprobiert und bin für mich zu dieser Lösung gekommen:



    ~/.gbp.conf


    Initiales Laden der Sourcen in Branch master

    Code
    git clone git:.../<paket>.git
    cd <paket>
    git branch
    * master


    Anlegen des Debian-Branch. Ich nenne ihn debian

    Code
    git checkout -b debian
    git branch
    * debian
      master


    debian-Verzeichnis anlegen

    Code
    mkdir debian
    Dateien im debian-Verzeichnis erzeugen/editieren
    git add debian
    git commit -m "initial version of debian directory"

    Das debian-Verzeichnis gibt es jetzt nur im Debian-Branch.


    Code
    cat debian/source/format 
    3.0 (quilt)


    Evtl. mit quilt Patches erzeugen/bearbeiten


    Paket bauen:


    Code
    git buildpackage -us -uc
    ...
    gbp:error: You are not on branch 'master' but on 'debian'
    gbp:error: Use --git-ignore-branch to ignore or --git-debian-branch to set the branch name.


    git-buildpackage lässt sich nur aus dem Debian-Branch starten (Default-Name ist master)
    Mein Debian-Branch heißt aber debian. Das gebe ich jetzt als Parameter mit:

    Code
    git buildpackage -us -uc --git-debian-branch=debian
    ...
    gbp:info: Orig tarball 'vdr_1.7.32.orig.tar.gz' not found at '../tarballs/'
    gbp:info: vdr_1.7.32.orig.tar.gz does not exist, creating from 'upstream/1.7.32'
    fatal: Not a valid object name upstream/1.7.32


    git-buildpackage nutzt defaultmässig zum Erzeugen des tar-Ball aus den Original-Sourcen ein Tag.
    Ich möchte, dass dazu der Branch genutzt wird:

    Code
    git buildpackage -us -uc --git-debian-branch=debian --git-upstream-tree=branch
    ...
    gbp:info: Orig tarball 'vdr_1.7.32.orig.tar.gz' not found at '../tarballs/'
    gbp:info: vdr_1.7.32.orig.tar.gz does not exist, creating from 'upstream'
    fatal: Not a valid object name upstream


    git-buildpackage will den tar-Ball jetzt aus dem Upstream-Branch erzeugen (Default-Name ist upstream)
    Deshalb müssen wir jetzt noch unseren Namen des Upstream-Branch bekannt machen:

    Code
    git buildpackage -us -uc --git-debian-branch=debian --git-upstream-tree=branch --git-upstream-branch=master
    ...


    Das läuft sauber durch.


    Die Parameter können auch ohne "--git-" in die Konfigurationsdatei ~/.gbp.conf aufgenommen werden.
    Dann kann man das Paket auch ohne Angabe der drei Parameter bauen.

    Code
    [git-buildpackage]
    export-dir = ../build-area/
    tarball-dir = ../tarballs/
    
    
    upstream-tree=branch
    upstream-branch=master
    debian-branch=debian


    Macht diese Vorgehensweise Sinn?
    Hat jemand einen anderen/besseren Weg?

    HW: Gigabyte EP41-UD3L | Core2Duo 7400 | 2GB Kingston | MSI N220GT-MD1GZ (passiv) | L4M-Twin S2 ver 6.5 mit Flex S2 | Silverstone LC16M mit iMON VFD | Samsung LE46B750
    SW: Xubuntu 14.04 3.13.0-24 | NVIDIA 304.117 | vdr 2.1.6 | softhddevice | inputlirc | lcdproc

  • Moin!


    Hast du meinen Vorschlag denn mal ausprobiert?
    Durch das lokale git-Repository hat man schon mal den master-Branch, in dem du dein debian-Verzeichnis einchecken kannst.
    Durch das Hinzufügen des remote "upstream" gibt es den Branch "upstream/master", also eigentlich so, wie git-buildpackage es erwartet.


    Ich werde das nachher mal ausprobieren, aber ich bin mir da ziemlich sicher, dass meine Variante funktioniert.


    Lars.

  • Durch das lokale git-Repository hat man schon mal den master-Branch, in dem du dein debian-Verzeichnis einchecken kannst.


    Einen Branch hat man erst nach dem ersten commit


    Zitat

    Durch das Hinzufügen des remote "upstream" gibt es den Branch "upstream/master", also eigentlich so, wie git-buildpackage es erwartet.


    Durch "git remote add upstream <url>" wird kein Branch angelegt. M.M.n wird dadurch nur eine Art "alias" für das Remote-Repository angelegt.


    Ich kenne mich aber eigentlich zu wenig aus und meine Aussagen sind nur Halbwissen.


    So wie du es geschrieben hast funktioniert es nicht.

    HW: Gigabyte EP41-UD3L | Core2Duo 7400 | 2GB Kingston | MSI N220GT-MD1GZ (passiv) | L4M-Twin S2 ver 6.5 mit Flex S2 | Silverstone LC16M mit iMON VFD | Samsung LE46B750
    SW: Xubuntu 14.04 3.13.0-24 | NVIDIA 304.117 | vdr 2.1.6 | softhddevice | inputlirc | lcdproc

  • Moin!


    Da ich git-buildpackage sowieso irgendwann kennenlernen wollte, hab ich mir deine Frage mal zum Anlass genommen und jetzt endlich mal die Doku gelesen. :)
    Grundsätzlich gilt: in den config-Dateien kannst du die verschiedenen Branches natürlich so benennen, wie du möchtest. Dafür ist das da.


    Wenn du möglichst mit den default-Werten arbeiten möchtest, schlage ich folgendes Vorgehen vor. Aber es ist wirklich nur ein Vorschlag...


    Zuerst ein leeres Repository für dein Paket anlegen

    Code
    mkdir <paket>
    cd <paket>
    git init


    Da dein upstream-Projekt auch schon git benutzt (schreibst du), kannst du die upstream-Sourcen folgendermaßen importieren:

    Code
    git remote add upstream <url>
    git fetch upstream


    Auch ein remote-Branch ist ein Branch, deshalb können wir daraus direkt unser master anlegen:

    Code
    git checkout -b master upstream/master


    Jetzt legst du das debian-Verzeichnis an und machst dort alle nötigen Änderungen:

    Code
    mkdir debian
    ...
    git add debian
    git commit -m "add debian directory"


    Dann hängt es davon ab, wie das upstream-Projekt seine Releases taggt, zur Not musst du das selbst machen.
    In meinem Beispiel hat das remote-Repository Tags in der Form "v%(version)s", d.h. Version "0.0.3a" ist getaggt als "v0.0.3a". Das lässt sich natürlich auch in der gbp.conf hinterlegen.

    Code
    git-buildpackage -uc -us --git-upstream-tag="v%(version)s"


    Und schon hab ich ein Paket.


    In deinem Fall ist es nicht so wichtig, ob dein orig-Tarball zu 100% dem Original entspricht, deshalb ist das schon in Ordnung so. Ansonsten kommt dieser ganze pristine-tar-Krimskrams ins Spiel. Das hab ich aber noch nicht ernsthaft gelesen... :)


    Wenn es jetzt neue Commits upstream gibt:

    Code
    git fetch upstream
    git merge upstream/master
    (nötige Änderungen am debian-Verzeichnis durchführen und committen, wichtig ist das changelog)
    dch -v 0.0.3b "new upstream release"
    git add debian
    git commit -m "new upstream release"
    git-buildpackage -uc -us --git-upstream-tag="v%(version)s"


    Und schon gibt's ein neues Paket mit der Version 0.0.3b.


    Etwas offtopic:
    Da es sinnvoll ist, seine eigenen Pakete auch etwas besser zu kennzeichnen, hängt man an die Versionsnummer noch ein Kürzel ran. Dabei muss man wissen, dass alles nach dem letzten Minuszeichen einer Versionsnummer nicht mehr zur Original-Versionsnummer gehört. Man darf also nicht zu viele Minuszeichen einbauen. :)
    Bei yaVDR würden wir in diesem Beispiel die Versionsnummer "0.0.3b-0yavdr0~precise" benutzen, d.h. bei uns so viel wie "erste Version des debian-Verzeichnisses (0 vor dem yavdr), erster build (0 nach dem yavdr), Plattform precise".
    Ist es ein vdr-Plugin, der vdr hat sich geändert und ich will das Plugin einfach neu bauen, wird die Versionsnummer geändert zu "0.0.3b-0yavdr1~precise".
    Muss ich Änderungen am debian-Verzeichnis vornehmen (z.B. neue build-deps), dann wird die erste Zahl hochgezählt und die zweite wieder auf Null gesetzt: "0.0.3b-1yavdr0~precise"
    Und wenn es einen neuen upstream-Release gibt, werden beide Zahlen wieder auf Null gesetzt: "0.0.3c-0yavdr0~precise"


    Aber da du deine Pakete nur lokal verwenden willst, ist es eher zweitrangig. Trotzdem lohnt es sich, sich darüber mal Gedanken zu machen.


    Was hälst du von diesem Vorgehen?


    Lars.

  • Hallo,


    du verzichtest darauf zwei getrennte Branches zu haben.
    Ich weiß noch nicht, ob ich die wirklich brauche. Aber in allen Dokus/Tutorials, die ich gesehen habe, gab es immer zwei getrennte Branches (siehe oben).


    Wo liegt der Unterschied zwischen deinen Zeilen

    Code
    mkdir <paket>
    cd <paket>
    git init
    git remote add upstream <url>
    git fetch upstream
    git checkout -b master upstream/master


    und

    Code
    git clone ...


    Siehe dazu auch dies



    Das Erzeugen des debian-Verzeichnis mache ich ja genau wie du.
    Bei der Versionsnummer habe ich "myvdr" genutzt wo du "yavdr" hast. Also auch gleich.


    Mit einer neuen Upstream-Version habe ich noch nicht getestet.


    Bei der Variante mit zwei Branches müsste es so gehen:
    git pull im Branch master
    git rebase im Branch debian
    git-dch
    git-buildpackage


    Bei der Variante mit einem Branch müsste es so gehen:
    git pull im Branch master
    git-dch
    git-buildpackage



    Für mich stellt sich eigentlich nur noch die Frage welche Vorteile die zwei getrennten Branches hätten.

    HW: Gigabyte EP41-UD3L | Core2Duo 7400 | 2GB Kingston | MSI N220GT-MD1GZ (passiv) | L4M-Twin S2 ver 6.5 mit Flex S2 | Silverstone LC16M mit iMON VFD | Samsung LE46B750
    SW: Xubuntu 14.04 3.13.0-24 | NVIDIA 304.117 | vdr 2.1.6 | softhddevice | inputlirc | lcdproc

  • Moin!


    du verzichtest darauf zwei getrennte Branches zu haben.


    Nein, tue ich nicht. Ich habe den lokalen Branch "master" für das debian-Verzeichnis, und den remote-Branch "upstream/master" für die Quellen des Originalpakets. Der heißt zwar remote, liegt ja aber trotzdem lokal in meinem git-Repository. :)


    Wo liegt der Unterschied zwischen deinen Zeilen


    Ein "git clone" erstellt ein neues lokales Repository und trägt das remote-Repository als "origin" ein. Danach hast du zwei Branches (vorausgesetzt, das Original benutzt nur master, was ich jetzt zur Vereinfachung einfach mal annehme), nämlich den lokalen "master" und den remote "origin/master". Das siehst du mit "git branch -a".
    Was ich mit dem "git remote add" mache, ist eigentlich das gleiche, nur nehme ich nicht den Standardnamen "origin", sondern nenne ihn "upstream", weil das der Name ist, den git-buildpackage per default für "das Original" benutzt.
    Als "origin" trägt man meisten ein Remote-Repository ein, für das man push-Rechte hat. Ist für externe Backups bei github.com o.ä. interessant (oder auch auf einem eigenen Server).


    Bei einem "git clone"-Aufruf passiert eigentlich folgendes im Hintergrund:

    Code
    mkdir <Repositoryname>
    cd <Repositoryname>
    git init
    git remote add origin <url>
    git fetch origin
    git checkout -b master origin/master


    Da man das aber nicht immer eintippen möchte, wurde "clone" erfunden. :)
    Ich hab jetzt gerade mal in die Manpage von git-clone geschaut, was ich mache, lässt sich auch folgendermaßen abkürzen:

    Code
    git clone --origin upstream <url> <Paketname>


    Das legt das Verzeichnis <Paketname> an, legt dort ein neues git-Repository an, trägt die <url> als remote "upstream" ein, holt die Daten und erstellt einen lokalen master-Branch, der auf upstream/master zeigt.
    Danach muss man also nur noch das debian-Verzeichnis anlegen und nach master einchecken.
    Nachteil hierbei: der lokale Branch "master" ist mit dem remote "upstream/master" verbunden. Wenn man also aus Versehen ein "git push" macht, versucht git, die Änderungen (also das debian-Verzeichnis) in das upstream-Repository zu schieben.
    Die einzige Möglichkeit, diese Verbindung aufzulösen, die ich bisher gefunden habe, ist, in .git/config den Abschnitt '[branch "master"]' zu löschen. Dann weiß "git push" nicht mehr, wohin mit dem Commits.



    Vorteil der getrennten Branches: In dem upstream-Branch liegt immer der Originalzustand der Quellen. Da kannst du dann auch jederzeit Updates reinziehen und nachsehen, was sich geändert hat. Man hat dann auch die originale changelog-History.
    Solange du in deinem Branch die Versionsnummer in debian/changelog nicht erhöhst, wird git-buildpackage immer den passenden (alten) Stand des Originals ziehen. Erst wenn du die Versionsnummer angepasst hast, wird der entsprechende Stand aus dem upstream-Branch geholt. Dadurch hast du im Prinzip die Möglichkeit, upstream-Versionen zu überspringen, falls die bekanntermaßen nicht für dich passen oder Fehler haben usw..


    Ich würde wahrscheinlich sogar mit drei Branches arbeiten:
    "master": mein lokaler Branch, in dem ich die Änderungen pflege, der zeigt auf "origin/master"
    "origin/master": ist ein Branch in einem remote-git, bei dem ich push-Rechte habe, z.B. bei meinem github-Account
    "upstream/master": ist ein Branch zu einem remote-git, bei dem ich nur pull-Rechte habe, eben das git-Repository des Programmautors.


    Der "origin"-Teil fehlt momentan in meiner Anleitung, weil du ja geschrieben hast, dass du nur lokal arbeiten möchtest.
    Der Vorteil eines externen eigenen Repositories ist (abgesehen vom Backup), dass man auch von anderen Rechnern aus arbeiten kann. Dazu klonst du dann dein eigenes Repository (wird automatisch als "origin" lokal eingetragen) und fügst dann wieder wie gehabt das upstream-remote-Repository hinzu. Und schon geht's weiter.


    Lars.

  • Hallo Lars,
    vielen Dank für deine ausführlichen Erläuterungen.
    ganz klar ist mir das aber immer noch nicht.



    Nein, tue ich nicht. Ich habe den lokalen Branch "master" für das debian-Verzeichnis, und den remote-Branch "upstream/master" für die Quellen des Originalpakets. Der heißt zwar remote, liegt ja aber trotzdem lokal in meinem git-Repository. :)


    O.k. dann habe ich drei Branches: origin/master, master, debian.
    Bei deiner Version werden doch nach einem erneuten pull die Sourcen im Branch master, in dem dein debian-Verzeichnis liegt, überschrieben. Bei mir erfolgt ein pull in den Branch master. Der Branch debian bleibt davon unberührt.
    Ahh, du machst dann wahrscheinlich nur ein fetch, um upstream/master zu aktualisieren, und kein pull (fetch + merge). Richtig?


    Zitat
    Code
    git clone --origin upstream <url> <Paketname>


    ...
    Nachteil hierbei: der lokale Branch "master" ist mit dem remote "upstream/master" verbunden. Wenn man also aus Versehen ein "git push" macht, versucht git, die Änderungen (also das debian-Verzeichnis) in das upstream-Repository zu schieben.


    Ist das bei der Variante mit "git remote add ..." und anschließendem "git checkout -b master origin/master" nicht auch der Fall?
    Kann man da nicht etwas mit "git checkout --no-track ..." machen?
    Bei der Variante mit dem separaten debian-Branch gäbe es das Problem nicht.


    Zitat


    Vorteil der getrennten Branches: In dem upstream-Branch liegt immer der Originalzustand der Quellen. Da kannst du dann auch jederzeit Updates reinziehen und nachsehen, was sich geändert hat. Man hat dann auch die originale changelog-History.


    Meinst du hier meinen separaten debian-Branch oder den lokalen upstream/master?


    Zitat


    Solange du in deinem Branch die Versionsnummer in debian/changelog nicht erhöhst, wird git-buildpackage immer den passenden (alten) Stand des Originals ziehen. Erst wenn du die Versionsnummer angepasst hast, wird der entsprechende Stand aus dem upstream-Branch geholt. Dadurch hast du im Prinzip die Möglichkeit, upstream-Versionen zu überspringen, falls die bekanntermaßen nicht für dich passen oder Fehler haben usw..


    Was meinst du hier mit "deinem Branch"?


    Guido

    HW: Gigabyte EP41-UD3L | Core2Duo 7400 | 2GB Kingston | MSI N220GT-MD1GZ (passiv) | L4M-Twin S2 ver 6.5 mit Flex S2 | Silverstone LC16M mit iMON VFD | Samsung LE46B750
    SW: Xubuntu 14.04 3.13.0-24 | NVIDIA 304.117 | vdr 2.1.6 | softhddevice | inputlirc | lcdproc

  • Moin!


    vielen Dank für deine ausführlichen Erläuterungen.


    Ich danke dir, dass ich mich endlich mal damit auseinandersetze. :)
    Wenn man etwas verstehen will, lernt man es am besten durch ausprobieren und indem man es jemand anderem erklärt. Dann muss man viel intensiver darüber nachdenken.


    O.k. dann habe ich drei Branches: origin/master, master, debian.


    Ok. Eigentlich machen wir wahrscheinlich das gleiche, nur unter anderem Namen. :)
    In deinem master-Branch liegen die upstream-Sourcen, in deinem debian-Branch zusätzlich das debian-Verzeichnis.
    Ich habe keinen extra lokalen Branch für die upstream-Sourcen, weil ich die ja nicht brauche, die sollen ja unverändert bleiben. Und in meinem master-Branch ist das debian-Verzeichnis.


    "master" bezeichnet eigentlich immer den Branch, wo die aktive Entwicklung des Repository-Besitzers stattfindet. In diesem Fall ist das "Projekt" ja nicht die upstream-Software, sondern die Paket-Entwicklung, sprich das debian-Verzeichnis.
    Deshalb liegt bei mir debian im Branch "master".


    Ahh, du machst dann wahrscheinlich nur ein fetch, um upstream/master zu aktualisieren, und kein pull (fetch + merge). Richtig?


    Vermutlich ja, noch habe ich ja nicht wirklich produktiv damit gearbeitet, habe es aber demnächst vor.
    Immer, wenn ich im changelog die Version hochzähle, muss ich den passenden Stand aus upstream nach master holen. Da kann ein "pull" über das Ziel hinausschießen, wenn in der Zwischenzeit schon die nächsten Commits für die übernächste Version im upstream-git sind.
    Deshalb mache ich dann einen merge auf den entsprechenden Versions-Tag.


    Kann man da nicht etwas mit "git checkout --no-track ..." machen?


    Ah, das kannte ich noch nicht, ja, das wird's sein.
    Werde ich gleich mal ausprobieren.


    Was meinst du hier mit "deinem Branch"?


    Der Branch, in dem du das debian-Verzeichnis verwaltest.


    Lars.

  • Moin!


    Hab meine Arbeitsweise jetzt noch mal neu dokumentiert:


    Neues Paket starten:

    Code
    mkdir <paketname>
    cd <paketname>
    git init
    git remote add upstream <url>
    git fetch upstream
    git checkout --no-track -b master <Versionstag>
    <debian-Verzeichnis anlegen>
    git add debian
    git commit -m "add debian directory"
    git-buildpackage -tc -uc -us (und evtl. --git-upstream-tag="v%(version)s" oder wie auch immer das upstream-Versions-Tag aussieht)


    Wenn es eine neue Version im upstream-git gibt:

    Code
    git fetch upstream
    git merge `git rev-list <Versions-Tag> | head -n 1`
    <evtl. debian-Dateien modifizieren>
    dch -v <neue Version inkl. Eigenanteil>
    git add debian
    git commit -m "update debian/changelog"
    git-buildpackage -tc -uc -us


    Nur der "git merge" stört mich noch. Ich hab aber noch keine leichtere Methode gefunden, um alles bis zu einem bestimmten Tag rüber in meinen master-Branch zu holen.


    Das nächste, womit ich mich mal beschäftigen werden, ist gbp-pq, also die quilt-Patches in einem eigenen Branch verwalten... :)


    Lars.

  • Ich habe keinen extra lokalen Branch für die upstream-Sourcen, weil ich die ja nicht brauche, die sollen ja unverändert bleiben. Und in meinem master-Branch ist das debian-Verzeichnis.


    Deshalb habe ich mich ja auch gefragt, ob ich noch einen zusätzlichen Branch brauche.
    Brauche ich also nicht.



    Hab meine Arbeitsweise jetzt noch mal neu dokumentiert:


    Neues Paket starten:
    ....


    Das Starten eines neuen Pakets werde ich mit "git clone" machen, aber wie bereits gesagt ist das ja sehr ähnlich.


    Zitat


    Wenn es eine neue Version im upstream-git gibt:
    ...
    Nur der "git merge" stört mich noch. Ich hab aber noch keine leichtere Methode gefunden, um alles bis zu einem bestimmten Tag rüber in meinen master-Branch zu holen.


    Wie wäre es mit (ungetestet)

    Code
    git ckeckout -b my_new_branch <tag>
    git checkout master
    git merge my_new_branch

    Ist zwar etwas länger, aber m.M.n verständlicher.


    Zitat


    Das nächste, womit ich mich mal beschäftigen werden, ist gbp-pq, also die quilt-Patches in einem eigenen Branch verwalten... :)


    Welchen Vorteil bringt dir das?
    Ich habe bisher nur direkt mit quilt herumprobiert.


    Guido

    HW: Gigabyte EP41-UD3L | Core2Duo 7400 | 2GB Kingston | MSI N220GT-MD1GZ (passiv) | L4M-Twin S2 ver 6.5 mit Flex S2 | Silverstone LC16M mit iMON VFD | Samsung LE46B750
    SW: Xubuntu 14.04 3.13.0-24 | NVIDIA 304.117 | vdr 2.1.6 | softhddevice | inputlirc | lcdproc

  • Moin!


    Wie wäre es mit (ungetestet)

    Code
    git ckeckout -b my_new_branch <tag>
    git checkout master
    git merge my_new_branch


    Ist zwar etwas länger, aber m.M.n verständlicher.


    Ja, aber dann müsste man hinterher wieder my_new_branch löschen, sonst sammeln sich da viele unnütze an. :)

    Code
    git branch -d my_new_branch


    (evtl. sogar mit großem "-D", muss ich mal ausprobieren, ob das kleine "-d" nicht meckert)
    Lässt sich eventuell leichter merken, für das andere kann man aber auch einen Alias o.ä. anlegen.



    Welchen Vorteil bringt dir das?
    Ich habe bisher nur direkt mit quilt herumprobiert.


    Das weiß ich noch nicht genau, muss das ja erst mal ausprobieren. :)
    Die Patches, die ich gegen upstream entwickle, kann ich dadurch in einem extra Branch verwalten. Und mit "gbp-pq export" werden daraus automatisch die quilt-Patches erzeugt.
    Ein Vorteil könnte sein, dass man "git rebase" auf dem patch-queue-Branch benutzen kann, um sie leichter an eine neue Upstream-Version anzupassen.
    Genaueres kann ich aber auch erst sagen, wenn ich damit mal ernsthaft gearbeitet habe. Momentan stört mich noch, dass die Infos aus den Patches (Beschreibung, Autor usw.) nicht übernommen und zurückgegeben werden. Es verschwinden auch Kommentare aus der series-Datei. Vielleicht weiß ich aber auch einfach noch nicht genau, wie ich das da reinschreiben muss.
    Ob's mir also wirklich hilft, weiß ich noch nicht.


    Wenn upstream kein git hat, finde ich auch "gbp-import-orig" ziemlich genial, insbesondere mit "pristine-tar"-Option. Damit kann man sich ziemlich schnell ein eigenes git-Repository aufbauen.


    Apropos "git clone": Hast du mal "gbp-clone" ausprobiert? Das könnte vielleicht das richtige für dich sein.
    Hast du schon http://honk.sigxcpu.org/projec…kage/manual-html/gbp.html durchgelesen? Ist nicht umfangreich und man muss auch nicht alles verstehen. Aber da gibt's durchaus den ein oder anderen Tipp.


    Lars.

  • Zitat


    Apropos "git clone": Hast du mal "gbp-clone" ausprobiert? Das könnte vielleicht das richtige für dich sein.

    Habe ich eben mal ausprobiert.
    Das erzeugt mit "gbp-clone git://git.gekrumbel.de/vdr.git" das gleiche wie "git clone ...", da es in dem upstrem-Repository nur den Branch master gibt.


    Zitat

    Ja, teilweise.
    Ich finde das hier auch ganz gut: Git Book
    Kann man auch als PDF herunterladen

    HW: Gigabyte EP41-UD3L | Core2Duo 7400 | 2GB Kingston | MSI N220GT-MD1GZ (passiv) | L4M-Twin S2 ver 6.5 mit Flex S2 | Silverstone LC16M mit iMON VFD | Samsung LE46B750
    SW: Xubuntu 14.04 3.13.0-24 | NVIDIA 304.117 | vdr 2.1.6 | softhddevice | inputlirc | lcdproc

  • Moin!


    Ja, teilweise.
    Ich finde das hier auch ganz gut: Git Book
    Kann man auch als PDF herunterladen


    Wollte ich auch schon immer mal lesen... :)


    Lars.

  • Moin!


    Nachtrag:

    Code
    git rev-list -1 <Tag>


    ist kürzer, als mit "head" abzuschneiden.


    Dann wird der merge zu:

    Code
    git merge `git rev-list -1 <Tag>`


    Ansonsten funktioniert ein "git branch -d my_new_branch" in deinem Beispiel.


    Das git-book ist gut. :)


    Lars.

  • Hallo Lars,


    das von dir genannte gbp.html hast du übrigens auch lokal.
    Schau mal unter /usr/share/doc/git-buildpackage/manual-html/gbp.html


    Und das manual ist auch noch gut.


    Und dann noch dies. Sehr gute Tipps.


    Guido

    HW: Gigabyte EP41-UD3L | Core2Duo 7400 | 2GB Kingston | MSI N220GT-MD1GZ (passiv) | L4M-Twin S2 ver 6.5 mit Flex S2 | Silverstone LC16M mit iMON VFD | Samsung LE46B750
    SW: Xubuntu 14.04 3.13.0-24 | NVIDIA 304.117 | vdr 2.1.6 | softhddevice | inputlirc | lcdproc

    3 Mal editiert, zuletzt von goldbär ()

  • Hallo,
    ich habe noch eine Frage, für die ich nicht extra einen neuen Thread aufmachen will. Deshalb stelle ich sie mal hier mit ein.


    Wie erkennt die Paketverwaltung beim Update eines Pakets bei welchen Dateien es sich um Konfigurationsdateien handelt?
    Diese sollten ja nicht überschrieben werden.


    Ich vermute, dass alles unter /etc als Konfiguration angesehen wird. Aber was ist dann mit den Dateien in /var/lib/vdr/?

    HW: Gigabyte EP41-UD3L | Core2Duo 7400 | 2GB Kingston | MSI N220GT-MD1GZ (passiv) | L4M-Twin S2 ver 6.5 mit Flex S2 | Silverstone LC16M mit iMON VFD | Samsung LE46B750
    SW: Xubuntu 14.04 3.13.0-24 | NVIDIA 304.117 | vdr 2.1.6 | softhddevice | inputlirc | lcdproc

  • Um genauer zu sein... (ist aus dem verlinkten Text evtl. nicht sofort ersichtlich)


    Jedes Packet liefert eine Liste mit (das erwähnte DEBIAN/conffiles), die angibt welche der (von diesem Paket installierten) Dateien Conffiles sind. Es sind also nicht zwingend alle Dateien unter /etc Conffiles. Und es können auch Dateien an anderen Orten Conffiles sein.


    Per Default wird diese Liste beim Paketbau mit allen Dateien, die vom Paket nach /etc installiert werden initialisiert.


    cu

Jetzt mitmachen!

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