git-dpm – Online in der Cloud

PROGRAMM:

NAME/FUNKTION

git-dpm – Debian-Pakete im Git-Manager

ZUSAMMENFASSUNG

git-dpm --help

git-dpm [ Optionen ] Befehl [ Optionen pro Befehl und -Argumente ]

BESCHREIBUNG

Git-dpm ist ein Tool zur Handhabung eines Debian-Quellpakets in einem Git-Repository.

Jedes Projekt enthält drei Zweige, einen Debian-Zweig (Master/was auch immer), ein gepatchter Zweig
(gepatcht/gepatcht-was auch immer) und ein Upstream-Zweig (flussaufwärts/stromaufwärts-was auch immer) und git-dpm
hilft Ihnen, die Informationen dort zu speichern, sodass Sie Ihre Änderungen als Quilt exportieren können
Serie.

Git-dpm errät die anderen beiden Zweige basierend auf dem Zweig, den es sieht. (Die meisten Befehle wirken
basierend auf dem aktuellen HEAD, dh dem Zweig, den Sie gerade ausgecheckt haben, obwohl einige als
z.B Status erlaubt stattdessen ein optionales Argument). Also zum Beispiel, wenn Sie in einer Filiale sind
Master, git-dpm geht davon aus, dass der entsprechende Upstream-Zweig aufgerufen wird flussaufwärts. Wenn Sie
in der Filiale upstream-etwas, geht es davon aus, dass der Debian-Zweig aufgerufen wird etwas.

Beachten Sie, dass die meisten Befehle möglicherweise automatisch zu einem anderen Zweig wechseln, teilweise weil dies der Fall ist
Auf diese Weise ist die Implementierung einfacher und man muss hoffentlich nicht den Zweig wechseln
manuell so oft.

NEUSTE ERLÄUTERUNG OF BRANCHEN

der Upstream-Zweig (flussaufwärts|stromaufwärts-was auch immer)
Dieser Zweig enthält die Upstream-Quellen. Sein Inhalt muss gleich genug sein
den Inhalt in Ihrem Upstream-Tarball.

der gepatchte Zweig (gepatcht|gepatcht-was auch immer)
Dieser Zweig enthält Ihre Patches für die Upstream-Quelle. Jeder Commit wird sein
als einzelner Patch im resultierenden Paket gespeichert.

Meistens wird es nicht als bekannter Zweig existieren git, aber nur irgendwann
in der Geschichte des Debian-Zweigs und möglicherweise als Tag für veröffentlichte Versionen.
Git-dpm erstellt ihn bei Bedarf und entfernt den Zweig, wenn er nicht mehr benötigt wird.

Um Git dabei zu helfen, eine lineare Patch-Serie zu generieren, sollte dies idealerweise eine lineare Kette von sein
Commits, deren Beschreibung für andere hilfreich ist.

Da dieser Zweig regelmäßig neu basiert, sollten Sie ihn nicht veröffentlichen.

der Debian-Zweig (Master|was auch immer)
Dies ist der Hauptzweig.

Dieser Zweig enthält die debian/ Verzeichnis und hat den gepatchten Zweig eingebunden.

Jede Änderung nicht in debian/, .git* oder das Löschen von Dateien muss im gepatchten erfolgen
Ast.

Beispiele:

Beginnen wir mit einigen Beispielen:

Ein Projekt auschecken
Holen Sie sich zuerst den Master-Zweig:
git klonen URL

Erstellen Sie dann einen Upstream-Zweig und prüfen Sie, ob .orig.tar bereit ist:
git-dpm vorbereiten

Erstellen Sie den gepatchten Zweig und prüfen Sie ihn:
git-dpm Checkout-gepatcht

Nehmen Sie einige Änderungen vor, wenden Sie einige Patches an, übernehmen Sie sie.
...
git verpflichten

Wenn Ihre Änderung eine frühere Änderung behebt (und das nicht das letzte Commit ist),
andernfalls hätten Sie --amend verwenden können), möchten Sie vielleicht diese beiden Commits unterdrücken
in eins, also verwenden Sie:
git zurückweisen -i flussaufwärts

Dann möchten Sie diese Änderungen in den Debian-Zweig und die neuen Patch-Dateien übernehmen
erstellt (was Sie mit tun können). git-dpm Update-Patches), aber Sie wollen höchstwahrscheinlich
um auch im Changelog zu dokumentieren, was Sie getan haben, also alles in einem Schritt:
git-dpm dch -- -i

Vielleicht etwas an der Debian-Verpackung ändern:
...
git verpflichten -a

Dann schieben Sie das Ganze zurück:
git drücken

Wechsel zu einer neuen Upstream-Version
Holen Sie sich eine neue .orig.tar-Datei. Aktualisieren Sie entweder Ihren Upstream-Zweig auf den Inhalt von
diese Datei und rufen Sie an git-dpm Rekord-Neu-Upstream ../Neue Sachen.orig.tar.gz oder erzählen
git-dpm zum Importieren und Aufzeichnen:
git-dpm import-new-upstream --rebase ../Neue Sachen.orig.tar.gz

Dadurch wird der gepatchte Zweig auf den neuen Upstream-Zweig umbasiert, vielleicht tun Sie das auch
Einige Konflikte müssen gelöst werden:
vim ...
git hinzufügen entschlossen Dateien
git zurückweisen --fortsetzen

Nachdem Rebase ausgeführt wurde (mit etwas Glück sogar beim ersten Versuch):
git-dpm dch -- -v newupstream-1 "neu flussaufwärts Ausführung"

Sie hätten den letzten Schritt in drei Schritten auch folgendermaßen ausführen können:
git-dpm Update-Patches
dch -- -v newupstream-1 "neu flussaufwärts Ausführung"
git verpflichten --ändern -a

Nehmen Sie weitere Debian-/Änderungen vor:
...
git verpflichten -a

Dann schieben Sie das Ganze zurück:
git drücken

Erstellen eines neuen Projekts
Erstellen Sie ein flussaufwärts (oder stromaufwärts-was auch immer)-Zweig, der den Inhalt Ihres enthält
orig.tar-Datei:
Teer -xvf Beispiel_0.orig.tar.gz
cd Beispiel-0
git init
git hinzufügen .
git verpflichten -m "importieren Beispiel_0.orig.tar.gz"
git Kasse -b upstream-instabil

Möglicherweise möchten Sie unberührten Teer verwenden, um Ihren Teer aufzubewahren:
makellos-tar verpflichten ../Beispiel_0.orig.tar.gz upstream-instabil

Dann teilen Sie git-dpm mit, zu welchem ​​Tarball Ihr Upstream-Zweig gehört:
git-dpm init ../Beispiel_0.orig.tar.gz

Beachten Sie, dass seit Sie drin waren upstream-instabil in diesem Beispiel, im letzten Beispiel
git-dpm Angenommen, Sie möchten, dass Ihr Debian-Zweig aufgerufen wird instabil und nicht Master, damit
Nachdem der Befehl zurückgegeben wurde, befinden Sie sich in der neu erstellten Datei instabil Ast.

Machen Sie den Rest der Verpackung:
vim Debian / Kontrolle debian/regeln
dch --schaffen --Paket Beispiel -v 0-1
git hinzufügen Debian / Kontrolle debian/regeln Debian/Änderungsprotokoll
git verpflichten -m "anfänglich Verpackung"

Fügen Sie dann einige Patches hinzu:
git-dpm Checkout-gepatcht
vim ...
git verpflichten -a
git-dpm dch "fixieren ... (Schließt: Anzahl)"

Das git-dpm Checkout-gepatcht hat einen temporären Zweig erstellt gepatcht-instabil (wie du
waren in einer Filiale namens instabil. Wenn Sie es mit HEAD als Zweig aufgerufen hätten
Master, es wäre gewesen gepatcht), zu dem Sie Commits hinzugefügt haben. Dann ist die git-dpm
Update-Patches behauptet von git-dpm dch hat diese Änderungen zusammengeführt in instabil, gelöscht
den temporären Zweig und erstellte einen neuen debian/patches/ Dateien.

Dann erstellen Sie Ihr Paket:
git-dpm Status &&
dpkg-buildpaket -Fakeroot -uns -uc -I".git*"

Schauen Sie sich nun an, was passiert ist. Vielleicht möchten Sie einige Dateien hinzufügen .gitignore (in
instabil Zweig) oder entfernen Sie einige Dateien aus dem instabil Zweig, weil Ihr
Die Clean-Regel entfernt sie.

Führen Sie die letzten Schritte fort, bis das Paket fertig ist. Dann pushen Sie Ihr Paket:
git-dpm Etikett
git drücken --Stichworte Ziel instabil:instabil Pristine-Teer: Pristine-Teer

Entfernen vorhandener Patches
Holen Sie sich zuerst den Master-Zweig:
git klonen URL

Erstellen Sie den gepatchten Zweig und prüfen Sie ihn:
git-dpm Checkout-gepatcht

Rufen Sie eine Liste der Commits seit der letzten Upstream-Version ab: git zurückweisen -i
upstream-instabil

Dadurch wird Ihr Standardeditor mit einer Liste von Commits geöffnet. Bearbeiten Sie die zu entfernende Liste
unerwünschte Commits.
...
git verpflichten

Dann möchten Sie diese Änderungen in den Debian-Zweig und die alten Patch-Dateien übernehmen
gelöscht (was Sie mit tun können). git-dpm Update-Patches), aber Sie wollen höchstwahrscheinlich
um auch im Changelog zu dokumentieren, was Sie getan haben, also alles in einem Schritt:
git-dpm dch -- -i

Vielleicht etwas an der Debian-Verpackung ändern:
...
git verpflichten -a

Dann schieben Sie das Ganze zurück:
git drücken

GLOBAL OPTIONAL

--debuggen
Geben Sie ausführlich aus, was git-dpm tut. Meistens nur nützlich zum Debuggen oder
bei der Erstellung eines Fehlerberichts.

--debug-git-calls
Geben Sie Git-Aufrufe an stderr aus. (Für kompliziertere Debugging-Fälle).

--allow-changes-in-debian-branch
Ignorieren Sie Upstream-Änderungen in Ihrem Debian-Zweig. Dadurch werden sie entweder verworfen, wenn
merge-patched wird vom Befehl „come“ aufgerufen oder an anderer Stelle ignoriert.

BEFEHLE

init [Optionen] Tardatei [Upstream-Commit [vorab angewendetes Commit [Patched-Commit]]]
Erstellen Sie ein neues Projekt.

Das erste Argument ist ein Upstream-Tarball.

Sie benötigen außerdem den Inhalt dieser Datei und der mitgegebenen Dateien
--component als Zweig oder Commit in Ihrem Git-Repository (oder ähnlichem) entpackt
genug so dpkg-Quelle werde den Unterschied nicht kennen). Dies wird im gespeichert
vorgelagerter Zweig (genannt flussaufwärts or stromaufwärts-was auch immer). Wenn das zweite Argument ist
Wenn der Zweig nicht vorhanden oder leer ist, muss er bereits vorhanden sein, andernfalls wird dieser Zweig vorhanden sein
mit dem zweiten Argument initialisiert werden. (Es liegt in Ihrer Verantwortung, dass die
Inhalte stimmen überein. git-dpm weiß nicht, was Ihre Clean-Regel bewirkt, kann es also nicht überprüfen
(und versucht noch nicht einmal zu warnen)).

Sie können bereits einen Debian-Zweig haben (genannt Master or was auch immer). Wenn es nicht
existiert, wird es danach existieren. Andernfalls kann es eine enthalten debian/patches/series
Datei, die git-dpm importiert.

Das dritte Argument kann ein Nachkomme Ihres Upstream-Zweigs sein, der das enthält
Änderungen an Ihrem Debian-Zweig, bevor Patches angewendet werden (die meisten Leute bevorzugen dies).
Habe keine und Lintian warnt, aber wenn du welche hast, übertrage/pflücke sie neu
Verzweigung/freistehender Kopf oben auf Ihrer vorgelagerten Verzweigung und benennen Sie sie hier). Ohne
--patches-applied, Ihr Debian-Zweig weist im Vergleich zu möglicherweise keine Upstream-Änderungen auf
dieses Commit (oder, falls es nicht angegeben ist, der Upstream-Zweig).

Wenn es kein viertes Argument gibt, wendet git-dpm mögliche Patches in Ihrem Debian an
Verzweigung über dem dritten Argument oder stromaufwärts. Sie können dies auch selbst tun und
Geben Sie das als viertes Argument an.

Der Inhalt dieses Commits/Zweigs, der im vierten Commit angegeben oder von erstellt wurde
Das Anwenden von Patches über dem dritten/Ihrem Upstream-Zweig wird dann mit Ihrem zusammengeführt
Debian-Zweig und als gepatchter Zweig gespeichert.

Zubehör:

--Komponente Dateinamen
Aufnehmen .orig-Komponente.Teer Datei, die in Ihrem Upstream-Zweig entpackt werden soll.

--patches-applied
Zeigt an, dass auf den Debian-Zweig die Patches bereits angewendet wurden.

Ohne dieses prüft git-dpm, ob im Debian-Zweig Änderungen vorgenommen wurden
externes Patch-Management vor der Anwendung der Patches; damit wird es
Überprüfen Sie stattdessen, ob nach der Anwendung der Patches keine Unterschiede bestehen.

--create-no-patches
Nicht erstellen/überschreiben debian/patches Verzeichnis. Sie müssen anrufen
Update-Patches selbst. Nützlich, wenn Sie historische Daten importieren und
Behalten Sie die Original-Patches im Debian-Zweig.

--record-patch-category
Hinzufügen Patch-Kategorie: Feld für jeden importierten Patch, der sich in einem Unterverzeichnis befindet
of debian/patches. Dies bewirkt Update-Patches um es darin aufzubewahren
Unterverzeichnis.

--record-patch-name
Hinzufügen Patch-Name: Feld jedem importierten Patch mit seinem Namen zu. Dies bewirkt
Update-Patches um es unter seinem ursprünglichen Namen zu speichern.

vorbereiten
Stellen Sie sicher, dass der Upstream-Zweig und der Upstream-Orig.tar-Ball vorhanden und auf dem neuesten Stand sind.
(Am besten nach einem Klon oder einem Pull benannt).

Status [Filiale]

Überprüfen Sie den Status des aktuellen Projekts (oder des dazugehörenden Projekts).
Argument Filiale wenn das gegeben ist). Gibt mit einem Exit-Code ungleich Null zurück, wenn etwas passiert
do wird erkannt.

Checkout-gepatcht

Schauen Sie sich den gepatchten Zweig an (gepatcht|gepatcht-was auch immer), nachdem Sie sichergestellt haben, dass es existiert
und ist in der aufgezeichnet debian/.git-dpm Datei.

Wenn der gepatchte Zweig auf einen alten Status verweist (d. h. einen, der bereits Vorfahr von ist
der aktuelle Debian-Zweig), wird in den aufgezeichneten aktuellen geändert.

Andernfalls können Sie es mit auf den zuletzt aufgezeichneten Zustand zurücksetzen --Macht .

Update-Patches [Optionen] [Zweigname]

Nach dem Anruf merge-patched-in-debian Aktualisieren Sie ggf. den Inhalt von
debian/patches zum aktuellen Stand der gepatcht Ast.

Notieren Sie außerdem in debian/.git-dpm, in welchem ​​Zustand des gepatchten Zweigs die Patches vorliegen
Verzeichnis gehört.

Sollten Sie jetzt aufgefordert werden, ein Zweigname gegeben ist, wird dieser Zweig abgearbeitet. Ansonsten wird der Name abgeleitet
aus der aktuell ausgecheckten Filiale wie gewohnt.

Zubehör:

--wiederholen Tun Sie etwas, auch wenn es so aussieht, als gäbe es nichts zu tun.

--allow-revert, --ignore-deletions, --dot-git-files=*
an merge-patched-into-debian weitergeleitet

--ändern
Erstellen Sie kein neues Commit, sondern ändern Sie das letzte im Debian-Zweig.
(Dh rufen Sie merge-patched-into-debian mit --amend auf und ergänzen Sie die Updates
Patches in den letzten Commit einfügen, auch wenn dieser nicht von erstellt wurde
merge-patched-in-debian).

-m Nachricht
Verwenden Sie die Nachricht als Commit-Nachricht. (Bei Verwendung zusammen mit --amend nicht wiederverwenden
alte Commit-Nachricht, Autor oder Autordatum, aber ersetzen Sie das alte Commit durch a
neues Commit mit dieser Nachricht).

--keep-branch
Entfernen Sie keinen vorhandenen gepatchten Zweig (normalerweise wird dieser entfernt und kann entfernt werden).
nachgebildet mit Checkout-gepatcht um zu vermeiden, dass veraltete Kopien herumliegen.

--allow-nonlinear
an merge-patched übergeben.

dch [Optionen] -- dch-Optionen
Führen Sie nach dem Aufruf von update-patches ggf. den dch von devscripts mit dem angegebenen aus
Optionen und dann a git verpflichten mit einer Commit-Nachricht, die Änderungen an der enthält
Debian/Änderungsprotokoll Datei.

Zubehör:

--ändern
Ersetzen Sie den Commit derzeit durch den Kopf des Debian-Zweigs
(Master|etwas), anstatt oben ein neues zu erstellen. Die Commit-Nachricht
werden auch Änderungen enthalten, die vorgenommen wurden Debian/Änderungsprotokoll im vorherigen Commit
(sofern nicht durch die neue Bearbeitung rückgängig gemacht).

--ignore-patches
Rufen Sie keine Update-Patches auf, sondern ignorieren Sie einfach den aktuellen Status des
gepatchter Zweig (gepatcht|gepatcht-etwas).

--keep-branch, --allow-revert, --allow-nonlinear, --ignore-deletions,
--dot-git-files=*
Wird bei Aufruf an update-patches übergeben.

--latest-only|--neueste|-l
Schließen Sie vor dem Aufruf nur Änderungen zwischen dem aktuellen Arbeitsverzeichnis ein
dch und nach dem Aufruf (und nicht seit dem letzten Commit oder dem letzten Commit).
nicht ersetzt).

-e | -v | -a | --alle | -s | -n | --no-verify | -u | --untracked-files | -q |
--ruhig | --cleanup=... | --author=...
an Git Commit übergeben.

merge-patched-in-debian [Optionen] [Zweigname]
Gewöhnlich Update-Patches führt dies bei Bedarf für Sie durch.

Dieser Befehl ist der Kern von git-dpm, aber normalerweise ruft man es nicht direkt auf. Es
wird von aufgerufen Update-Patches und Dinge, die rufen Update-Patches Gefällt mir dch wann
notwendig.

Es ersetzt alle Dateien (mit nur den unten beschriebenen Ausnahmen) im aktuellen
Debian-Zweig (Master|was auch immer) mit denen, die im gepatchten Zweig gefunden wurden
(gepatcht|gepatcht-was auch immer).

Nur der Debian Verzeichnis und Dateien im Stammverzeichnis, die mit „.git“ beginnen
aus dem Debian-Zweig ferngehalten (so .gitignore, .gittributes, ... werde bleiben). Und
Alle Dateien, die im zuletzt aufgezeichneten gepatchten Zweig gefunden und im gelöscht wurden
Der aktuelle Debian-Zweig wird auch im neuen gelöscht.

Zusätzlich die debian/.git-dpm Die Datei wird aktualisiert, sodass der aktuell gepatchte Zweig angezeigt wird
wird aufgezeichnet und als zum zuletzt aufgezeichneten Upstream-Zweig gehörend markiert.

Wenn es nein gibt Zweigname Geben Sie in der Befehlszeile den Basisnamen der Zweige ein
Der zu bearbeitende Zweig wird wie gewohnt aus dem aktuell ausgecheckten Zweig berechnet. Ansonsten
Dieses Argument wird verwendet.

Zubehör:

--allow-revert
Normalerweise ist das Zurücksetzen auf einen alten Zustand des gepatchten Zweigs nicht zulässig
Vermeiden Sie Fehler (z. B. wenn Sie nur den Debian-Zweig gezogen und vergessen haben, ihn auszuführen).
Checkout-gepatcht). Diese Option ändert das, sodass Sie beispielsweise das löschen können
letzter Patch in Ihrem Stapel.

--no-ignore-deletions (Default)
Derzeit im Debian-Zweig gelöschte Dateien im Verhältnis zu den aufgezeichneten Dateien
Der gepatchte Zweig wird im neuen Debian-Zweig weiterhin gelöscht und nicht übernommen
aus dem neuen gepatchten Zweig. Dies ist die Standardeinstellung, es sei denn, es handelt sich um eine andere Standardeinstellung
wurde mit eingestellt
git Config dpm.ZWEIGNAME.dpmIgnoreDeletions was immer dies auch sein sollte..

--ignore-deletions
Deaktivieren Sie das unter beschriebene Verhalten --no-ignore-deletions.

--dot-git-files=Methode
Geben Sie an, wie Dateien mit beginnen .git aussen debian/ werden abgewickelt. Jene sind
Griffe speziell als .gittributes und .gitignore könnte in der anders sein
Debian-Zweig, ohne Teil eines Patches zu sein. (Das Ganze debian/ Verzeichnis
wird immer aus dem Debian-Zweig entnommen, daher sind die Dateien dort nicht betroffen).

Mögliche Methoden sind:

maschinell (Default)
Jedes .git* Dateien, die im aktuellen hinzugefügt, geändert oder entfernt werden
Debian-Zweig im Vergleich zum alten Upstream-Zweig sind darauf eingestellt
Zustand, alles andere wird so übernommen, wie es im neuen gepatchten Zweig zu finden ist.

Debian Unser .git* Dateien stammen aus dem Debian-Zweig. Dateien mit einem Namen
solche aus dem gepatchten Zweig werden ignoriert.

flussaufwärts
Dateien beginnen mit .git werden nicht besonders behandelt. Sie sind
werden aus dem gepatchten Zweig übernommen, sofern sie nicht im Debian gelöscht werden
Zweig und die Standardeinstellung --no-ignore-deletions ist aktiv. (also gerade
wie jede andere Datei draußen debian/).

--keep-branch
Entfernen Sie keinen vorhandenen gepatchten Zweig (normalerweise wird dieser entfernt und kann entfernt werden).
nachgebildet mit Checkout-gepatcht um zu vermeiden, dass veraltete Kopien herumliegen).

--ändern
Ersetzen Sie den letzten Commit in Ihrem Debian-Zweig (wie es git commit --amend tun würde).
Tun). Mit der Ausnahme, dass jeder Elternteil ein Vorfahre von oder gleichgestellt ist
zum neuen gepatchten Zweig oder der aufgezeichnete gepatchte Zweig wird weggelassen. (Das
Das heißt, Sie verlieren nicht nur das Commit auf dem Debian-Zweig, sondern auch ein vorheriges
Status des gepatchten Zweigs, wenn Ihr letzter Commit auch den gepatchten Zweig zusammengeführt hat
Ast).

-m Nachricht
Commit-Nachricht, die für den neu erstellten Commit verwendet werden soll. (Bei Verwendung zusammen mit
--amend, dies deaktiviert die Wiederverwendung des alten Autors und Datums).

--allow-nonlinear
Brechen Sie nicht mit einem Fehler ab, wenn der gepatchte Zweig keine lineare Reihe von ist
Commits über dem Upstream-Zweig. Die Verwendung dieser Option wird nicht empfohlen
da es leicht Probleme mit gepatchten oder Upstream-Zweigen verbirgt und möglicherweise
Führen Sie defekte Debian/Patches/-Serien ein, da Format-Patch dies nicht tut
Serialisierung.

import-new-upstream [Optionen] .orig.tar
Importieren Sie den Inhalt der angegebenen TAR-Datei (wie bei import-tar) und notieren Sie dies
Zweig (wie bei Rekord-Neu-Upstream).

Dies entspricht in etwa:
git-dpm import-tar -p flussaufwärts Dateinamen
git Kasse -b flussaufwärts
git-dpm Rekord-Neu-Upstream Dateinamen

--löste sich
Machen Sie den neuen Upstream-Zweig nicht zum Vorfahren des alten Upstream-Zweigs
(es sei denn, Sie fügen das erneut mit hinzu -p).

-p Commit-ID|--Elternteil Commit-ID
ABSICHT import-tar Zusätzliche übergeordnete Elemente des neuen Commits zum Erstellen.

Wenn Sie beispielsweise das Git-Repository des Upstreams in einem Zweig verfolgen, können Sie dies tun
Benennen Sie das hier, um es zu einem Teil der Geschichte Ihres Debian-Zweigs zu machen.

--allow-no-parent
Wenn dpm.importWithoutParent über die Git-Konfiguration auf „false“ gesetzt ist, ist dies bei git-dpm nicht der Fall
Ermöglichen Sie die Ausführung von import-new-upstream ohne diese Option oder zumindest auf -p
.

--rebase-patched
Nachdem Sie den neuen Upstream-Zweig aufgezeichnet haben, führen Sie ein Rebase des gepatchten Zweigs auf den durch
neuer Upstream-Zweig.

--no-rebase-patched
Rufen Sie rebase-patched nicht auf, nachdem Sie den neuen Upstream-Zweig aufgezeichnet haben. (Das
ist derzeit die Standardeinstellung, aber das kann sich in Zukunft ändern).

-m Nachricht
Commit-Nachricht, die für das neue Commit an den Debian-Zweig verwendet werden soll, der die Aufzeichnung aufzeichnet
neue Datei und Upstream-Zweig.

--Komponente Paketversion.orig-Komponente.Teergz
Entpacken Sie den angegebenen Dateinamen in das Komponente Verzeichnis und notieren Sie es so
zur Verbesserung der Gesundheitsgerechtigkeit vorbereiten und Status Ich weiß, dass ich danach suchen muss.

--drin

Es existiert noch keiner der Zweige. Erstellen Sie ihn.

Da die zu bearbeitenden Zweige abgeleitet sind KOPF wenn nein --Zweig Option ist
gegeben, du brauchst entweder KOPF auf einen noch nicht existierenden Zweig verweisen (z
direkt danach git init) oder Sie müssen einen Namen angeben --Zweig.
Andernfalls existiert einer der Zweige bereits und Sie erhalten nur eine Fehlermeldung
Nachricht.

--Zweig debianbranch
Leiten Sie den Namen des Debian-Zweigs nicht vom aktuellen ab KOPF aber verwenden debianbranch
stattdessen. (Und der Name des Upstream-Zweigs und der Name des gepatchten Zweigs sind abgeleitet von
das wie immer).

--pristine-tar-commit | --ptc
Telefon makellos-tar verpflichten für alle importierten Tarballs, die noch nicht im gefunden wurden
unberührter Teerzweig.

--no-pristine-tar-commit
Ruf nicht an makellos-tar verpflichten für alle importierten Tarballs, auch wenn sie konfiguriert sind
um dies zu tun
git Config dpm.pristineTarCommit was immer dies auch sein sollte. oder von
git Config Ast.debianbranch.dpmPristineTarCommit was immer dies auch sein sollte..

--ignore-deletions, --dot-git-files=
Wird bei Aufruf an merge-patched übergeben (wird nur durchgeführt, wenn keine Patches vorhanden sind
vorher).

--upstream-Autor Autor
Verwendet als --Autor Argument zwei git-dpm import-tar.

--upstream-date Datum
Verwendet als --Datum Argument zwei git-dpm import-tar (insbesondere Auto is
unterstützt, um ein Datum aus der TAR-Datei zu extrahieren).

--ausschließen Anleitungen
Das angegebene Muster wird beim Entpacken als Ausschlussmuster an tar übergeben. Kann
mehrfach gegeben werden.

import-tar [Optionen] .tar-Datei
Erstellen Sie ein neues Commit, das den Inhalt der angegebenen Datei enthält. Das Commit wird nicht ausgeführt
Haben Sie keine Eltern, es sei denn, Sie geben -p Optionen.

-p Commit-ID|--Elternteil Commit-ID
Fügen Sie das angegebene Commit als übergeordnetes Element hinzu. (Kann mehrfach angegeben werden).

--Zweig Zweigname
Erstellen Sie einen neuen Zweig Zweigname falls noch nicht vorhanden, oder ersetzen
Zweigname mit einem Commit, der aus dem Tarball mit dem aktuellen erstellt wurde
Zweigname Kopf als Elternteil.

-m Nachricht
Starten Sie keinen Editor für die Commit-Nachricht, sondern verwenden Sie stattdessen das Argument.

--Datum Datum
Datum des zu erstellenden Commits.

Wenn der Wert ist Auto dann das neueste Datum einer Datei oder eines Verzeichnisses in der
Tarball wird verwendet.

--Autor Autor
Autor des zu erstellenden Commits. Es muss im üblichen Git-Format vorliegen
Autor <E-Mail>.

--ausschließen Anleitungen
Das angegebene Muster wird beim Entpacken als Ausschlussmuster an tar übergeben. Kann
mehrfach gegeben werden.

Rekord-Neu-Upstream [Optionen] .orig.tar [verpflichten]

Wenn Sie den Upstream-Zweig geändert haben (flussaufwärts|stromaufwärts-was auch immer), git-dpm muss
wissen, welchem ​​Tarball dieser Zweig jetzt entspricht, und Sie müssen Ihren neu basieren
gepatchter Zweig (gepatcht|gepatcht-was auch immer) zum neuen Upstream-Zweig.

Wenn ein zweites Argument vorhanden ist, ersetzt dieser Befehl zunächst Ihren Upstream-Zweig
mit dem angegebenen Commit.

Dann wird der neue Upstream-Zweig in Ihrem Debian-Zweig aufgezeichnet debian/.git-dpm
Datei.

Wenn Sie angegeben haben --rebase-patched (oder kurz --rebase), git-dpm rebase-gepatcht werden wir
aufgerufen werden, um Ihren gepatchten Zweig auf den neuen Upstream-Zweig umzubasieren.

Danach (und wenn der Zweig dann Ihren Wünschen entspricht) müssen Sie dies noch tun
rufen Sie uns an! git-dpm merge-patched-in-debian (oder direkt git-dpm Update-Patches).

WARNUNG Um Missverständnissen vorzubeugen: Sie müssen den Upstream-Zweig ändern
bevor Sie diesen Befehl verwenden. Es liegt in Ihrer Verantwortung, den Inhalt sicherzustellen
Tarball stimmen mit denen des Upstream-Zweigs überein.

--rebase-patched
Automatisch anrufen git-dpm rebase-gepatcht.

--new-tarball-only
Verweigern Sie den Vorgang nicht, wenn sich der Tarball ändert, der Upstream-Zweig jedoch
nicht. (Dies ist nur sinnvoll, wenn sich der Tarball geändert hat, ohne ihn zu ändern
Inhalt siehe Warnung oben).

-m Nachricht
Commit-Nachricht, die für das neue Commit an den Debian-Zweig verwendet werden soll, der die Aufzeichnung aufzeichnet
neue Datei und Upstream-Zweig.

--ändern
Ersetzen Sie den letzten Commit, anstatt darüber einen neuen zu erstellen.

--Komponente Dateinamen
Rekord Dateinamen nach Bedarf Komponentenquelldatei (z. B. a
Quellname_Upstreamversion.orig-Komponente.Teer.Werkzeugen Datei). Es ist dein
dafür verantwortlich, dass der Inhalt dieser Datei bereits Teil Ihres Upstreams ist
Zweig (in a Komponente Unterverzeichnis).

(Aufgezeichnete Dateien werden gesucht von Status und vorbereiten. Die Liste der
Aufgezeichnete Komponentenquelldateien werden entfernt, wenn ein neuer Upstream-Zweig oder
flussaufwärts .orig Quelldatei aufgezeichnet wird).

--ignore-deletions, --ot-git-files=
Wird bei Aufruf an merge-patched übergeben (was nur geschieht, wenn keine vorhanden sind).
Patches zuvor, so dass der neue Upstream-Zweig direkt eingebunden wird).

rebase-gepatcht
Versuchen Sie, Ihren aktuell gepatchten Zweig neu zu starten (gepatcht|gepatcht-was auch immer) zu deinem
aktueller aktueller Upstream-Zweig (flussaufwärts|stromaufwärts-was auch immer).

Wenn diese Zweige noch nicht als Git-Zweige vorhanden sind, werden sie aus dem (neu) erstellt
Informationen aufgezeichnet in debian/.git-dpm zuerst.

Dies ist nur ein praktischer Wrapper für Git Rebase, der zunächst versucht, dies zu ermitteln
Was genau ist Rebase? Wenn es Konflikte gibt, werden Sie von Git Rebase dazu aufgefordert
Lösen Sie sie und weisen Sie Rebase an, fortzufahren.

Nachdem dies abgeschlossen ist (und wenn der Zweig dann so aussieht, wie Sie es möchten), können Sie immer noch
technische merge-patched-in-debian (oder direkt Update-Patches).

Etikett [ Optionen ] [ Version ]
Fügen Sie Tags zu den Upstream-, Patched- und Debian-Zweigen hinzu. Wenn keine Version angegeben ist, ist es
stammt aus debian/changelog.

Zubehör:

--Aktualisierung
Überschreiben Sie die Tags, wenn sie bereits vorhanden sind und sich unterscheiden (außer Upstream).

--refresh-upstream
Überschreiben Sie den Upstream, falls dieser vorhanden ist und sich unterscheidet.

--allow-stale-patches
Machen Sie keinen Fehler, wenn Patches nicht auf dem neuesten Stand sind. Dies ist nur sinnvoll, wenn Sie
importieren historische Daten und möchten diese mit Tags versehen.

--genannt
Verwenden Sie den Paketnamen als Teil der Namen der generierten Tags. (verwenden git
Config dpm.tagsNamed was immer dies auch sein sollte. um dies als Standard festzulegen)

--with-name Name
Like --genannt aber geben Sie den zu verwendenden Namen an.

--debian-tag Verlinke den Namen

--patched-tag Verlinke den Namen

--upstream-tag Verlinke den Namen
Geben Sie die Namen der zu generierenden Tags an.

%p wird durch den Paketnamen ersetzt,

%v mit der Version (ohne Epoche) durch Doppelpunkte (:) und Tilde (~) ersetzt
durch Unterstrich (_),

%u mit der Upstream-Version (ohne Epoche oder Debian-Revision) mit Doppelpunkten
(:) und Tilde (~) durch Unterstrich (_) ersetzt,

%e mit der Epoche,

%f mit der Epoche, gefolgt von einem Unterstrich (_), wenn es eine Epoche gibt, und
mit der leeren Zeichenfolge, wenn es keine Epoche gibt,

%V mit der Version (ohne Epoche) durch Doppelpunkte (:) und Tilde (~) ersetzt
durch Punkte (.),

%U mit der Upstream-Version (ohne Epoche oder Debian-Revision) mit Doppelpunkten
(:) und Tilde (~) durch Punkte (.) ersetzt,

%E mit der Epoche, gefolgt von einem Punkt, wenn es eine Epoche gibt, und mit dem Leerzeichen
Zeichenfolge, wenn es keine Epoche gibt,

%% mit einem einzigen %.

Wenn einer davon nicht über die Befehlszeilenoption festgelegt ist, git Config wird gefragt
Wert von dpm.debianTag, dpm.patchedTag or dpm.upstreamTag. Wenn das auch nicht eingestellt ist
oder der besondere Wert AUTO, dann wird debian/.git-dpm nach einer Zeile des Formulars durchsucht
debianTag="Wert",
patchedTag="Wert" or
upstreamTag="Wert".

(Hinweis: Fügen Sie diese immer am Ende der Datei hinzu, die ersten acht Zeilen sind festgelegt
Linien Nummern)

Wenn dies immer noch nicht zu einem zu verwendenden Muster führt, werden die Standardeinstellungen verwendet
'%p-debian%e-%v','%p-patched%e-%v'Und'%p-upstream%e-%u' mit --genannt und
'debian%e-%v','gepatcht%e-%v'Und'stromaufwärts%e-%u' ohne.

Wenn ein Tag-Name den Sonderwert hat NONE, wird kein Tag generiert.

Ref-Tag [ Optionen ] verpflichten [ Version ]
Like Etikett, aber erstellen Sie Tags für verpflichten, Ie verpflichten erhält das Debian-Tag und das
Andere Tags werden dort platziert, wo die debian/.git-dpm Datei, auf die dieser Commit verweist.

Es ist also größtenteils gleichbedeutend mit:
git Kasse -b Temp. verpflichten
git-dpm Etikett [Optionen] [Version]
git Kasse vorheriger Kopf
git Filiale -D Temp.

Optionen wie Etikett.

Apply-Patch [ Optionen... ] [ Dateinamen ]
Wechseln Sie zum gepatchten Zweig (vorausgesetzt, er ist aktuell, verwenden Sie zuerst checkout-patched).
um sicherzugehen oder eine Warnung zu erhalten) und wenden Sie den als Argument oder von angegebenen Patch an
std.

--Autor Autor
Überschreiben Sie den aufzuzeichnenden Autor.

--defaultauthor Autor
Wenn aus dem Commit kein Autor ermittelt werden konnte, verwenden Sie dies.

--Datum Datum
Datum, an dem dieser Patch ursprünglich aufgezeichnet wurde, falls nicht gefunden.

--dpatch
Patch als Dpatch-Patch analysieren (Funktioniert nur für Dpatch-Patches, die tatsächlich ein
Patch, kann bei anderen stillschweigend fehlschlagen).

--cdbs Analysieren Sie den Patch als cdbs simple-patchsys.mk-Patch (Funktioniert nur für Dpatch-Patches
Da es sich tatsächlich um einen Patch handelt, kann es für andere stillschweigend scheitern.

--bearbeiten Starten Sie einen Editor, bevor Sie den Commit durchführen (falls Sie zu faul sind, Änderungen vorzunehmen).

--record-name
Hinzufügen Patch-Name: Feld zu erzählen Update-Patches um es mit demselben zu exportieren
wieder benennen.

--Name Name
Hinzufügen Patch-Name: Feld zu erzählen Update-Patches benutzen Name als Dateiname an
Speichern Sie diesen Patch in (relativ zu debian/patches).

--Kategorie Name
Hinzufügen Patch-Kategorie: Feld zu erzählen Update-Patches um dies immer zu exportieren
Patch in ein Unterverzeichnis kopieren Name of debian/patches.

Kirsche-Pick [ Optionen... ] verpflichten
Erstellen Sie den gepatchten Zweig neu und wählen Sie den angegebenen Commit aus. Dann füge das wieder zusammen
in den Debian-Zweig und aktualisieren Sie das Verzeichnis debian/patches (d. h. meistens
entspricht Checkout-Patched, Git's Cherry-Pick und Update-Patches).

--merge-only
Führen Sie den gepatchten Zweig nur wieder mit dem Debian-Zweig zusammen, führen Sie jedoch kein Update durch
das Patches-Verzeichnis (Sie müssen später update-patches ausführen, um dies zu erhalten
getan).

-e | --bearbeiten
Übergeben an Gits Cherry-Pick: Bearbeiten Sie die ausgewählte Commit-Nachricht.

-s | --abmelden
Übergeben an Gits Rosinenpick: Fügen Sie einen Signed-off-by-Header hinzu

-x Übergeben an Gits Rosinenpick: Fügen Sie eine Zeile hinzu, die beschreibt, was ausgewählt wurde

-m num | --mainline num
Übergeben an Gits Cherry-Pick: Ermöglicht die Auswahl einer Zusammenführung durch Angabe des übergeordneten Elements
zu betrachten.

--wiederholen
Nicht abbrechen, wenn der angegebene Commit bereits enthalten ist.

--allow-nonlinear, --ignore-deletions, --dot-git-files=
Wird bei Aufruf an update-patches übergeben.

übergeben an merge-patched-into-debian und update-patches.

--keep-branch
Entfernen Sie den gepatchten Zweig nicht, wenn er nicht mehr benötigt wird.

--ändern
übergeben an merge-patched-into-debian: Ändert den letzten Commit im Debian
Ast.

import-dsc
Importieren Sie ein Debian-Quellpaket aus einer .dsc-Datei. Dies kann zum Erstellen eines neuen verwendet werden
Projekt oder um ein Quellpaket in ein bestehendes Projekt zu importieren.

Während ein möglicher alter Status eines Projekts als übergeordnetes Commit aufgezeichnet wird, ist der Status von
der alte Debian-Zweig wird nicht berücksichtigt. Insbesondere alle Dateilöschungen und
.gitignore-Dateien und dergleichen müssen anschließend erneut angewendet/hinzugefügt werden.
(Es wird davon ausgegangen, dass neue Quellpaketversionen von außen möglicherweise Änderungen vornehmen
erheblich, so dass alte Informationen mit größerer Wahrscheinlichkeit veraltet sein könnten. Und es erneut anwenden
ist einfacher, als solche Änderungen rückgängig zu machen.)

Der erste Schritt ist das Importieren .orig.tar Datei und möglich .orig-Komponente.Teer Dateien.
Sie können entweder einen zu verwendenden Zweig angeben. Ansonsten import-dsc Werde schauen ob das
Der vorherige Stand dieses Projekts verfügt bereits über die benötigte Datei, also den alten Upstream
Zweig kann wiederverwendet werden. Ist dies nicht der Fall, wird die Datei als neues Commit importiert.
standardmäßig mit einem möglichen vorherigen Upstream-Zweig als übergeordnetem Zweig.

Dann import-dsc Ich werde versuchen, das Quellpaket im Status als zu importieren dpkg-Quelle
-x würde es schaffen. (Das bedeutet, die .diff-Datei anzuwenden und zu erstellen debian/regeln ausführbar
für Pakete im 1.0-Format und Ersetzen der Debian Verzeichnis mit dem Inhalt von a
.debian.tar und Anwendung möglich debian/patches/series für Pakete im 3.0-Format).
Dies wird später als wörtlicher Import bezeichnet.

Wenn es sich um ein 1.0-Quellformatpaket handelt, import-dsc sucht dann nach einer Reihe von unterstützten
Patchsysteme und versucht, diese Patches anzuwenden. Diese werden dann mit dem zusammengeführt
wörtlicher Zustand in den neuen Debian-Zweig.

Dann wird ein debian/.git-dpm Die Datei wird erstellt und ein möglicher alter Stand des Projekts
als übergeordnetes Element hinzugefügt.

Beachten Sie, dass dpkg-Quelle wird nicht zum Extrahieren von Paketen verwendet, sondern sie werden extrahiert
manuell. Besonders git-apply wird anstelle von Flicken. Während dies im Allgemeinen
funktioniert (und git-dpm hat etwas Magie, von dem man einiges umgehen kann git-apply's Mängel),
Unsaubere Patches benötigen möglicherweise manchmal eine - C0 Option und dann in den gleichen Fällen angewendet werden
an anderen Positionen als wo Flicken würde sie anwenden.

Allgemeine Optionen:

-b | --Zweig Zweigname
Schauen Sie sich nicht den aktuellen HEAD an, sondern importieren Sie das Paket in git-dpm
Projekt Zweigname oder erstellen Sie ein neues Projekt (falls dieser Zweig dies noch nicht tut).
existieren).

--wörtlich Zweigname
Nach der import-dsc erfolgreich abgeschlossen, Zweigname wird die enthalten
wörtlicher Import der .dsc-Datei. Wenn bereits ein Zweig mit diesem Namen existiert,
Das neue wörtliche Commit hat auch das alte als übergeordnetes Element. (Dies verursacht auch
Das wörtliche Commit wird nicht mit anderen Änderungen ergänzt, die daraus resultieren können
in mehr Commits).

--use-changelog
Analysieren Sie debian/changelog des importierten Pakets. Verwenden Sie die Beschreibung als
Commit-Nachrichten sowie der Autor und die Uhrzeit als Standard für Patches und Import
begeht ohne diese Informationen. (Achtung: Kann noch etwas Rough enthalten
Kanten).

Optionen zum Erstellen des Upstream-Zweigs:

--upstream-to-use verpflichten
Importieren Sie nicht .orig.tar und versuchen Sie nicht, einen alten Import wiederzuverwenden, sondern verwenden Sie immer
verpflichten spezifiziert.

Es liegt in Ihrer Verantwortung, dass dieser Zweig dem ähnlich genug ist
.orig.tar-Datei plus eventuell .orig-component.tar in ihrer jeweiligen Datei
Verzeichnisse. (Ähnlich genug bedeutet wie üblich: Es werden keine Dateien übersehen
Ihre Patches berühren oder Ihr Build-Prozess erfordert (oder erstellt neu, es sei denn).
debian/regeln reinigen entfernt sie wieder). Jede Datei anders als in
.orig.tar oder dort nicht vorhanden ist, müssen Sie im resultierenden Debian löschen
Zweig. Kein Patch darf diese Dateien berühren.)

Mit Vorsicht verwenden. Nichts wird Sie warnen, selbst wenn Sie den Inhalt von a verwenden
Völlig falsche Upstream-Version.

--detached-upstream
Wenn Sie eine .orig.tar-Datei als neues Commit importieren, führen Sie kein mögliches Commit durch
eine alte übergeordnete Version der Upstream-Version.

--upstream-parent verpflichten
Speichern verpflichten als (zusätzliches) übergeordnetes Element, wenn eine neue Upstream-Version importiert wird.

(Dies kann zum Beispiel verwendet werden, um den Git-Verlauf des Upstreams zu einem Teil Ihres zu machen
Paketverlauf und helfen so Git bei der Rosinenauswahl).

--allow-no-parent
Wenn dpm.importWithoutParent über die Git-Konfiguration auf „false“ gesetzt ist, ist dies bei git-dpm nicht der Fall
Erlauben Sie, dass import-dsc ohne oder zumindest mit dieser Option ausgeführt wird
--upstream-parent-Option.

--pristine-tar-commit |--ptc
Telefon makellos-tar verpflichten für alle nach dem Rest importierten Tarballs
Der Befehl import-dsc war erfolgreich.

--no-pristine-tar-commit
Ruf nicht an makellos-tar verpflichten für alle importierten Tarballs, auch wenn sie konfiguriert sind
um dies zu tun
git Config dpm.pristineTarCommit was immer dies auch sein sollte. oder von
git Config Ast.debianbranch.dpmPristineTarCommit was immer dies auch sein sollte..

--upstream-Autor Autor
Verwendet als --Autor Argument zwei git-dpm import-tar.

--upstream-date Datum
Verwendet als --Datum Argument zwei git-dpm import-tar (insbesondere Auto is
unterstützt, um ein Datum aus der TAR-Datei zu extrahieren).

--tar-exclude Anleitungen
Das angegebene Muster wird beim Entpacken als Ausschlussmuster an tar übergeben
Tarfiles. Kann mehrfach gegeben werden.

Optionen zum Anwenden von Patches:

-f | --force-commit-reuse
Schauen Sie sich beim Versuch nur noch das übergeordnete Element und den Baum an und nicht mehr die Beschreibung
Wiederverwendung von Commits zum Importieren von Patches aus früheren Paketversionen.

-Cnum | --patch-context num
Bestanden als -Cnum zu git-apply. Gibt die Anzahl der Kontextzeilen an
muss passen.

--dpatch-allow-empty
Geben Sie keinen Fehler aus, wenn eine dpatch-Datei bei der Behandlung als nichts ändert
patch.

Da es sich bei dpatch-Dateien um beliebige Skripte handeln kann, git-dpm hat ein paar probleme
Erkennen, ob es sich wirklich um Patches handelt. (Es kann nur Patches verarbeiten). Wenn
Ein Skript, das kein Patch ist, wird als Patch behandelt, der normalerweise dazu führt
Patch ändert nichts, daher sind diese ohne diese Option verboten.

--patch-system Modus
Geben Sie an, welches Patch-System für Pakete im Quellformat 1.0 verwendet wird.

Auto (Dies ist die Standardeinstellung)
Versuchen Sie herauszufinden, welches Patch-System verwendet wird debian/regeln
(und Debian / Kontrolle).

keine Das sind nicht die Patches, die Sie suchen.

Geschichte
Versuchen Sie nicht, Patches in der .diff-Datei zu finden (z. B keine). Wenn wenn das
Das Projekt existiert bereits und der Upstream-Tarball ist derselbe. Erstellen Sie ihn
den gepatchten Zustand des neuen, indem die Patches des alten verwendet werden
und das Hinzufügen eines Stücks Top, um es in den neuen Zustand zu bringen.

Wenn Sie mehrere Revisionen eines Pakets importieren, wobei jede neue
Revision hat höchstens eine einzige Änderung zum Upstream hinzugefügt, diese Option
ermöglicht es Ihnen, fast automatisch einen geeigneten Satz Patches zu erstellen
(idealerweise fehlen nur Beschreibungen).

Wenn es dieselben Änderungen und Rücksetzungen gibt, werden diese im angezeigt
Es werden keine Patches erstellt, daher ist dieser Modus in diesem Fall nicht sehr nützlich.

Steppdecke Extrahieren und anwenden a debian/patches/series Quiltartige Serie darüber
mögliche Upstream-Änderungen in der .diff-Datei.

Quilt-First
Da die Steppdecke Modus, aber wenden Sie die Patches auf einen unveränderten Upstream an
Wählen Sie zuerst die in der .diff-Datei gefundenen Änderungen aus und wählen Sie sie dann aus.

Da dies nicht die normale Reihenfolge ist, in der Patches angewendet werden
Beim Entpacken/Erstellen-Zyklus schlägt dies fehl, wenn diese Änderungen nicht eindeutig sind
genug (z. B. wenn Patches von Änderungen abhängen, die im vorgenommen wurden
.diff).

Aber wenn die .diff-Datei nur unabhängige Änderungen enthält, variiert das mit
Bei jeder Version ergibt sich eine viel schönere Geschichte als bei den Commits für die
Patches können einfacher wiederverwendet werden.

Quilt-appliziert
Da die Quilt-First Gehen Sie jedoch davon aus, dass die Patches bereits angewendet wurden
in der .diff-Datei, also wenden Sie sie auf einen unveränderten Upstream an und dann
Fügen Sie einen Commit hinzu, der ihn in den Status in der .diff-Datei bringt. (Oder auch nicht, wenn das so ist
(Patch wäre leer).

dpatch | dpatch-first | dpatch-angewendet
Wie die Steppdecke bzw. Quilt-First bzw. Quilt-appliziert Modi, aber
Suchen Sie stattdessen nach Patches im Dpatch-Stil in debian/patches/00list.

Beachten Sie, dass nur Patches unterstützt werden und dpatch, das andere ausführt, nicht unterstützt wird
Befehle.

einfach | einfach-zuerst | einfach anzuwenden
Wie die Steppdecke bzw. Quilt-First bzw. Quilt-appliziert Modi, aber
stattdessen annehmen debian/patches/ Enthält Patches, die für CDBS geeignet sind
simple-patchsys.mk.

--patch-Autor "Name <E-Mail>"
Legen Sie den Autor für alle Git-Commits fest, die Patches importieren.

--patch-default-author "Name <E-Mail>"
Legen Sie einen Autor für alle Patches fest, die keine Autoreninformationen enthalten (oder wo).
git-dpm kann es nicht bestimmen).

--edit-patches
Starten Sie für jeden importierten Patch einen Editor für die Commit-Nachricht.

--record-patch-category
Hinzufügen Patch-Kategorie: Feld für jeden importierten Patch, der sich in einem Unterverzeichnis befindet
of debian/patches. Dies bewirkt Update-Patches um es darin aufzubewahren
Unterverzeichnis.

--record-patch-name
Hinzufügen Patch-Name: Feld jedem importierten Patch mit seinem Namen zu. Dies bewirkt
Update-Patches um es unter seinem ursprünglichen Namen zu speichern.

record-dsc [Optionen] verpflichten .dsc-Datei
Speichern Sie eine makellose .dsc-Datei in einem dscs Zweig nach dem Speichern der darin enthaltenen Dateien
mit reinem Teer.

Das erste Argument ist ein Tag oder Commit, das das speichert git-dpm Projekt im Land
gehört zu .dsc Datei und das zweite Argument ist die .dsc Datei selbst. Der
Dateien, auf die es verweist, werden im selben Verzeichnis wie die Datei selbst erwartet (falls vorhanden).
wird gebraucht).

Es werden einige Überprüfungen durchgeführt, um sicherzustellen, dass die Datei und ihr Inhalt richtig benannt sind
mit dem betreffenden Commit übereinstimmen, aber nur oberflächlich, um offensichtliche Fehler zu vermeiden (z
Beispielsweise wird nur die Version überprüft, aber .debian.tar wird nicht entpackt, um die zu überprüfen
Dateien sind zum Beispiel wirklich gleich).

Zubehör:

--create-branch
Erstelle eine neue dscs Ast.

--allow-unsigned
Aufnahme ohne Vorzeichen zulassen .dsc Datei. Dies verfehlt normalerweise den Sinn von
sie überhaupt aufzubewahren.

debian/.git-dpm Datei

Sie sollten den Inhalt dieser Datei nicht kennen müssen, außer zum Debuggen von git-dpm.

Die Datei enthält 8 Zeilen, zukünftige Versionen können jedoch mehr enthalten.

Die erste Zeile gibt einen Hinweis darauf, worum es in dieser Datei geht, und wird ignoriert.

Dann gibt es 4 Git-Commit-IDs für die aufgezeichneten Zustände:

Zuerst der Status des gepatchten Zweigs, wenn die Patches eingespielt wurden debian/patches waren die letzten
aktualisiert.

Dann der Zustand des gepatchten Zweigs, als er das letzte Mal in Debian eingebunden wurde
Ast.

Dann der Status des Upstream-Zweigs, als der gepatchte Zweig zuletzt zusammengeführt wurde.

Endlich der Upstream-Zweig.

Die folgenden 3 Zeilen sind der Dateiname, die SHA1-Prüfsumme und die Größe des Origtarballs
Zugehörigkeit zum aufgezeichneten Upstream-Zweig.

KURZSCHNITTE

Die meisten Befehle haben auch kürzere Aliase, um die Eingabe von Folgendem zu vermeiden:

Update-Patches: up, up, ci
vorbereiten: vorbereiten
checkout-patched: co, cp
rebase-patched: rp
Apply-Patch: ap
import-tar: it
import-new-upstream: inu, inu
record-new-upstream: rnu, rnu
merge-patched-in-debian: merge-patched

record-new-upstream ist auch unter dem alten Namen new-upstream verfügbar, wird es aber wahrscheinlich tun
in zukünftigen Versionen entfernt werden (um Verwirrung zu vermeiden).

BRANCHEN

der Upstream-Zweig (flussaufwärts|stromaufwärts-was auch immer)
Dieser Zweig enthält die Upstream-Quellen. Der Inhalt muss gleich genug sein
den Inhalt in Ihrem Upstream-Tarball.

Gleich genug bedeutet, dass dpkg-source keinen Unterschied zwischen Ihren gepatchten sehen sollte
Baum und Original-Tarball ausgepackt, der Patch angewendet und debian/regeln
reinigen laufen. Normalerweise ist es am einfachsten, einfach den wörtlichen Inhalt Ihres Originals zu speichern
Tarball hier. Dann können Sie es auch für makellosen Teer verwenden.

Dieser Zweig kann ein Unterverzeichnis debian/ enthalten, das normalerweise einfach ignoriert wird.

Sie können diesen Zweig entweder veröffentlichen oder ihn nur implizit über die sichtbar machen
debian/.git-dpm Datei im Debian-Zweig.

Während es normalerweise sinnvoll ist, dass neuere Upstream-Zweige ältere enthalten, ist dies der Fall
wird nicht benötigt. Sie sollten in der Lage sein, von einem selbst erstellten oder einem anderen zu wechseln
Das Foreign-VCS-Importtool generierte einen in einen nativen Upstream-Zweig oder umgekehrt
ohne Probleme. Beachten Sie, dass der Debian-Zweig den gepatchten Zweig als hat
Vorfahr und der gepatchte Zweig der Upstream-Zweig, Ihre Upstream-Zweige sind
Teil der Geschichte Ihres Debian-Zweigs. Das hat den Vorteil, dass man es kann
Stellen Sie den genauen Status Ihrer Filialen direkt aus Ihrem Verlauf wieder her (z. B git
Kasse -b alter Staat myoldtagorshaofdebianbranchcommit ; git-dpm vorbereiten ; git
Kasse instabiler alter Zustand), aber der Nachteil besteht darin, diese Historien zu entfernen
Von Ihrem Repository aus müssen Sie einige manuelle Arbeiten ausführen.

der gepatchte Zweig (gepatcht|gepatcht-was auch immer)
Dieser Zweig enthält Ihre Patches für die Upstream-Quelle. (was natürlich bedeutet
es basiert auf Ihrem Upstream-Zweig).

Jeder Commit wird als einzelner Patch im resultierenden Paket gespeichert.

Um Git dabei zu helfen, eine lineare Patch-Serie zu generieren, sollte dies idealerweise eine lineare Kette von sein
Commits, deren Beschreibung für andere hilfreich ist.

Da dieser Zweig regelmäßig einem Rebase unterzogen wird, sollten Sie ihn nicht veröffentlichen. Stattdessen können Sie
Erstellen Sie diesen Zweig mit neu git-dpm Checkout-gepatcht Verwendung der in gespeicherten Informationen
debian/.git-dpm.

Es ist Ihnen nicht gestattet, den Inhalt zu ändern debian/ Unterverzeichnis in diesem
Zweig. Das Umbenennen oder Löschen von Dateien verursacht normalerweise unnötig große Patches.

der Debian-Zweig (Master|was auch immer)
Dies ist der Hauptzweig.

Dieser Zweig enthält die debian/ Verzeichnis und hat den gepatchten Zweig eingebunden.

Jede Änderung nicht in debian/, .git* oder das Löschen von Dateien muss im gepatchten erfolgen
Ast.

alternative Filialnamen
Sie können alternative Zweignamen für Upstream- und gepatchte Zweige von a angeben
Sie können einen bestimmten Debian-Zweig festlegen oder einen Zweig dazu zwingen, ein Debian-Zweig zu sein, der dies normalerweise tun würde
B. vorgelagerter Zweig eines anderen Zweiges durch Hinzufügen berücksichtigt werden dpmUpstreamBranch
und dpmPatchedBranch Konfigurieren Sie Elemente für den betreffenden Debian-Zweig (Sie benötigen
beide, nur einer wird als Fehler behandelt).

Das folgende Beispiel ist für alle praktischen Zwecke ein No-Op:
git Config branch.master.dpmUpstreamBranch flussaufwärts
git Config branch.master.dpmPatchedBranch gepatcht

COPYRIGHT

Copyright © 2009,2010 Bernhard R. Link
Dies ist freie Software; die Kopierbedingungen finden Sie in der Quelle. Es gibt KEINE Garantie; nicht
sogar für MARKTFÄHIGKEIT oder EIGNUNG FÜR EINEN BESTIMMTEN ZWECK.

REPORTING Fehler UND PROBLEME

Sie können Fehler oder Funktionsvorschläge an melden [E-Mail geschützt] oder
Mich. Bitte senden Sie Fragen an [E-Mail geschützt] oder zu mir unter
[E-Mail geschützt] .

Verwenden Sie git-dpm online über die Dienste von onworks.net