Einzelne Patches

Der Befehl git send-email ist die beste Art, wie Sie sowohl einzelne Patches als auch Patch-Reihen (siehe Mehrere Patches) an die Guix-Mailing-Liste schicken können. Würden Sie Patches als E-Mail-Anhänge schicken, wäre es in manchen Mailprogrammen umständlich, diese zu überprüfen. Und wenn Sie aus git diff kopierten, würden die Metadaten des Commits fehlen.

Anmerkung: Der Befehl git send-email ist in der Ausgabe namens send-email des git-Pakets enthalten, also git:send-email.

Mit dem folgenden Befehl erzeugen Sie eine E-Mail mit dem Patch aus dem neuesten Commit, öffnen diese in Ihrem gewählten EDITOR oder VISUAL, um sie zu bearbeiten, und schicken sie an die Guix-Mailing-Liste, damit jemand sie überprüft und merget. Vorausgesetzt Sie haben Git bereits so eingerichtet wie in Abschnitt Git einrichten beschrieben, können Sie einfach dies benutzen:

$ git send-email --annotate -1

Tipp: Wenn Sie in der Betreffzeile zu Ihrem Patch ein zusätzliches Präfix mitgeben möchten, können Sie die Befehlszeilenoption --subject-prefix benutzen. Beim Guix-Projekt wird so angegeben, dass der Patch für einen bestimmten Branch oder ein anderes Repository bestimmt ist, statt für den master-Branch von https://git.savannah.gnu.org/cgit/guix.git.

git send-email --annotate --subject-prefix='PATCH core-updates' -1

In der Patch-E-Mail finden Sie eine Trennlinie aus drei Bindestrichen unter der Commit-Nachricht. Sie dürfen erklärende Bemerkungen zum Patch unterhalb dieser Linie anbringen. Wenn Sie keine solchen Annotationen in der E-Mail schreiben möchten, können Sie oben auf die Befehlszeilenoption --annotate verzichten.

Wenn Sie einen überarbeiteten Patch schicken müssen, geht das anders. Machen Sie es nicht so und schicken Sie keinen Patch mit einem „Fix“, der als Nächstes angewandt werden müsste, sondern verwenden Sie stattdessen git commit --amend oder git rebase, um den alten Commit zu verändern, und schicken den an die Adresse FEHLERNUMMER@debbugs.gnu.org, wobei Sie außerdem die Befehlszeilenoption -v von git send-email angeben.

$ git commit --amend
$ git send-email --annotate -vREVISION \
      --to=FEHLERNUMMER@debbugs.gnu.org -1

Anmerkung: Offenbar gibt es einen Fehler in git send-email, wodurch Sie nicht -v REVISION (mit einem Leerzeichen) schreiben dürfen; lediglich -vREVISION funktioniert.

Die FEHLERNUMMER finden Sie heraus, indem Sie entweder auf der Mumi-Oberfläche auf https://issues.guix.gnu.org nach dem Namen Ihres Patches suchen oder indem Sie in Ihren E-Mails auf die Eingangsbestätigung schauen, die Debbugs Ihnen automatisch als Antwort auf eingehende Fehlerberichte (Bugs) und Patches hat zukommen lassen. Darin finden Sie die Fehlernummer.

Teams ansprechen

Wenn Ihr Git-Ckeckout richtig eingerichtet ist (siehe Git einrichten), wird der Befehl git send-email automatisch die Mitglieder des zuständigen Teams benachrichtigen. Dazu analysiert das Skript etc/teams.scm Ihre Änderungen. Sie können es auch selbst aufrufen, wenn Sie den zum Einreichen von Patches bevorzugten Befehl git send-email meiden. Um die verfügbaren Aktionen für dieses Skript zu lesen, können Sie es mit dem Befehl etc/teams.scm help aufrufen. Für weitere Informationen über Teams siehe den Abschnitt Teams.

Anmerkung: Auf Fremddistributionen müssen Sie vielleicht stattdessen ./pre-inst-env git send-email aufrufen, damit Sie etc/teams.scm benutzen können.

Mehrere Patches

Obwohl git send-email allein für einen einzelnen Patch genügt, führt eine Unzulänglichkeit in Debbugs dazu, dass Sie beim Versenden mehrerer Patches achtgeben müssen: Wenn Sie alle auf einmal an die Adresse guix-patches@gnu.org schicken würden, würde für jeden Patch jeweils ein Fehlerbericht eröffnet!

Wenn Sie die Patches aber als Patch-Reihe abschicken wollen, sollten Sie als Erstes mit Git ein „Deckblatt“ schicken, das den Gutachtern einen Überblick über die Patch-Reihe gibt. Zum Beispiel können Sie ein Verzeichnis namens ausgehend anlegen und darin sowohl Ihre Patch-Reihe als auch ein Deckblatt namens 0000-cover-letter.patch platzieren, indem Sie git format-patch aufrufen.

$ git format-patch -NUMBER_COMMITS -o outgoing \
      --cover-letter

Anmerkung: git format-patch accepts a wide range of revision range specifiers. For example, if you are working in a branch, you could select all commits in your branch starting at master.

$ git format-patch master..MY_BRANCH -o outgoing \
      --cover-letter

Jetzt schicken Sie nur das Deckblatt an die Adresse guix-patches@gnu.org, so dass ein Fehlerbericht aufgemacht wird, an den wir dann die restlichen Patches schicken können.

$ git send-email ausgehend/0000-cover-letter.patch --annotate
$ rm ausgehend/0000-cover-letter.patch # nicht nochmal schicken!

Passen Sie auf und bearbeiten die E-Mail nochmal, um ihr vor dem Abschicken eine angemessene Betreffzeile (Subject) und anstelle von Blurb Ihren Text mitzugeben. Sie werden bemerken, dass unterhalb des Textes automatisch ein Shortlog und Diffstat aufgelistet wurden.

Sobald Sie vom Debbugs-Mailer eine Antwort auf Ihre Deckblatt-E-Mail erhalten haben, können Sie die eigentlichen Patches an die neu erzeugte Adresse für diesen Fehlerbericht senden.

$ git send-email ausgehend/*.patch --to=FEHLERNUMMER@debbugs.gnu.org
$ rm -rf ausgehend # wir sind damit fertig

Zum Glück können wir uns diesen Tanz mit git format-patch danach sparen, wenn wir eine überarbeitete Patch-Reihe schicken, weil wir die Fehlernummer dann bereits haben.

$ git send-email -ANZAHL_COMMITS -vREVISION \
      --to=FEHLERNUMMER@debbugs.gnu.org

Wenn nötig, können Sie mit --cover-letter --annotate auch dann ein weiteres Deckblatt mitschicken, z.B. um zu erklären, was die Änderungen seit der letzten Revision sind und warum sie nötig waren.