git-format-patch - Online in de cloud

PROGRAMMA:

NAAM

git-format-patch - Bereid patches voor voor verzending via e-mail

KORTE INHOUD

git formaat-patch [-k] [(-o|--uitvoermap) | --stdout]
[--geen draad | --draad[= ]]
[(--bijvoegen|--inline)[= ] | --geen bijlage]
[-s | --afmelden]
[--handtekening= | --geen handtekening]
[--handtekeningbestand= ]
[-n | --genummerd | -N | --geen nummer]
[--startnummer ] [--genummerde bestanden]
[--in-reply-to=Bericht-ID] [--achtervoegsel=. ]
[--negeer-als-in-stroomopwaarts]
[--subject-prefix=Onderwerp-voorvoegsel] [(--reroll-count|-v) ]
[--naar= ] [--cc= ]
[--[geen-]sollicitatiebrief] [--stil] [--notities[= ]]
[ ]
[ | ]

PRODUCTBESCHRIJVING

Bereid elke commit voor met zijn patch in één bestand per commit, geformatteerd om op UNIX te lijken
mailbox formaat. De uitvoer van deze opdracht is handig voor het verzenden van e-mail of voor gebruik
met git am.

Er zijn twee manieren om aan te geven op welke commits moet worden gewerkt.

1. Eén enkele commit, , specificeert dat de commits leiden tot het topje van de stroom
tak die niet voorkomt in de geschiedenis die leidt naar de uitgang te zijn.

2. Generiek expressie (zie het gedeelte "HERZIENINGEN SPECIFICEREN" in
gitrevisies(7)) betekent de commits in het gespecificeerde bereik.

In het geval van een single heeft de eerste regel voorrang . Om de tweede toe te passen
regel, dat wil zeggen: formatteer alles vanaf het begin van de geschiedenis tot en met , gebruik de
--wortel optie: git format-patch --root . Als u alleen wilt formatteren
zelf kun je dit doen met git format-patch -1 .

Standaard wordt elk uitvoerbestand opeenvolgend genummerd vanaf 1 en wordt de eerste regel gebruikt van
het commit-bericht (gemasseerd voor de veiligheid van de padnaam) als de bestandsnaam. Met de
--numbered-files optie, zullen de uitvoerbestandsnamen alleen uit cijfers bestaan, zonder de eerste
regel van de commit toegevoegd. De namen van de uitvoerbestanden worden afgedrukt naar standaarduitvoer,
tenzij de optie --stdout is opgegeven.

Als -o is opgegeven, worden uitvoerbestanden gemaakt in . Anders worden ze gemaakt in de
huidige werkmap.

Standaard is het onderwerp van een enkele patch "[PATCH]", gevolgd door de aaneenschakeling van
regels vanaf het commit-bericht tot aan de eerste lege regel (zie de DISCUSSION-sectie van
git-commit(1)).

Wanneer er meerdere patches worden uitgevoerd, zal het onderwerpvoorvoegsel in plaats daarvan "[PATCH n/m] " zijn. Naar
forceer 1/1 om toe te voegen voor een enkele patch, gebruik -n. Om patchnummers uit het onderwerp weg te laten:
gebruik -N.

Als --thread wordt opgegeven, zal git-format-patch In-Reply-To en References headers genereren
laat de tweede en volgende patchmails verschijnen als antwoorden op de eerste mail; dit ook
genereert een Message-Id-header waarnaar moet worden verwezen.

OPTIES

-p, --no-stat
Genereer gewone patches zonder diffstats.

-s, --geen-patch
Onderdruk diff-uitvoer. Handig voor commando's zoals git show die de patch laten zien door
standaard, of om het effect van --patch te annuleren.

-U , --unified=
Genereer diffs met contextregels in plaats van de gebruikelijke drie.

--minimaal
Besteed extra tijd om ervoor te zorgen dat het kleinst mogelijke verschil wordt geproduceerd.

--geduld
Genereer een diff met behulp van het algoritme "geduld diff".

--histogram
Genereer een diff met behulp van het algoritme "histogram diff".

--diff-algoritme={geduld|minimaal|histogram|myers}
Kies een diff-algoritme. De varianten zijn als volgt:

standaard, myers
Het fundamentele hebzuchtige diff-algoritme. Momenteel is dit de standaard.

minimaal
Besteed extra tijd om ervoor te zorgen dat het kleinst mogelijke verschil wordt geproduceerd.

geduld
Gebruik het "geduld diff"-algoritme bij het genereren van patches.

histogram
Dit algoritme breidt het geduldalgoritme uit om "weinig voorkomend gemeenschappelijk gedrag te ondersteunen."
elementen".

Als u bijvoorbeeld de variabele diff.algorithm hebt geconfigureerd op een niet-standaardwaarde en
Als je de standaard wilt gebruiken, dan moet je de optie --diff-algorithm=default gebruiken.

--stat[= [, [, ]]]
Genereer een diffstat. Standaard wordt zoveel ruimte gebruikt als nodig is voor de
bestandsnaamgedeelte en de rest voor het grafiekgedeelte. De maximale breedte is standaard ingesteld op terminal
breedte, of 80 kolommen indien niet verbonden met een terminal, en kan worden overschreven door .
De breedte van het bestandsnaamgedeelte kan worden beperkt door een andere breedte op te geven
na een komma. De breedte van het grafiekgedeelte kan worden beperkt door gebruik te maken van
--stat-grafiekbreedte= (is van invloed op alle opdrachten die een statistische grafiek genereren) of door
instelling diff.statGraphWidth= (heeft geen invloed op git format-patch). Door het geven van een
derde parameter , kunt u de uitvoer beperken tot de eerste lijnen, gevolgd
door ... als er meer zijn.

Deze parameters kunnen ook individueel worden ingesteld met --stat-width= ,
--stat-naam-breedte= en --stat-count= .

--getalstat
Vergelijkbaar met --stat, maar toont het aantal toegevoegde en verwijderde regels in decimale notatie en
padnaam zonder afkorting, om het machinevriendelijker te maken. Voor binaire bestanden:
geeft twee uitgangen - in plaats van 0 0 te zeggen.

--kortstat
Voer alleen de laatste regel van het --stat-formaat uit, met daarin het totale aantal wijzigingen
bestanden, evenals het aantal toegevoegde en verwijderde regels.

--dirstat[= ]
Voer de verdeling van het relatieve aantal wijzigingen voor elke submap uit. De
Het gedrag van --dirstat kan worden aangepast door er een door komma's gescheiden lijst van door te geven
parameters. De standaardinstellingen worden bepaald door de configuratievariabele diff.dirstat
(Zie git-config(1)). De volgende parameters zijn beschikbaar:

veranderingen
Bereken de dirstat-getallen door de regels te tellen die uit het bestand zijn verwijderd
bron of toegevoegd aan de bestemming. Dit negeert de hoeveelheid pure code
bewegingen binnen een bestand. Met andere woorden, het herschikken van regels in een bestand is dat niet
evenveel geteld als andere wijzigingen. Dit is het standaardgedrag als er geen parameter is
is gegeven.

lijnen
Bereken de dirstat-getallen door de reguliere lijngebaseerde diff-analyse uit te voeren, en
het optellen van de verwijderde/toegevoegde regels. (Voor binaire bestanden tel je chunks van 64 bytes
in plaats daarvan, aangezien binaire bestanden geen natuurlijk concept van lijnen hebben). Dit is een meer
duur --dirstat-gedrag dan het veranderingsgedrag, maar het telt wel mee
herschikte regels binnen een bestand net zo goed als andere wijzigingen. De resulterende uitvoer is
consistent met wat u krijgt van de andere --*stat-opties.

bestanden
Bereken de dirstat-nummers door het aantal gewijzigde bestanden te tellen. Ieder veranderde
bestand telt evenveel mee in de dirstat-analyse. Dit is rekenkundig het goedkoopst
--dirstat gedrag, omdat het helemaal niet naar de bestandsinhoud hoeft te kijken.

cumulatieve
Tel wijzigingen in een onderliggende map ook voor de bovenliggende map. Let daar op
bij cumulatief kan de som van de gerapporteerde percentages groter zijn dan 100%. De
standaard (niet-cumulatief) gedrag kan worden gespecificeerd met het niet-cumulatieve
parameter.


Een geheel getalparameter specificeert een afkappercentage (standaard 3%). Telefoonboeken
die minder dan dit percentage van de veranderingen bijdragen, worden niet weergegeven in de uitvoer.

Voorbeeld: Het volgende telt de gewijzigde bestanden, terwijl mappen met minder worden genegeerd
dan 10% van het totale aantal gewijzigde bestanden, en het accumuleren van de aantallen onderliggende mappen
in de bovenliggende mappen: --dirstat=files,10,cumulatief.

--samenvatting
Voer een verkorte samenvatting uit van uitgebreide headerinformatie, zoals creaties en hernoemingen
en moduswijzigingen.

--geen-hernoemen
Schakel hernoemingsdetectie uit, zelfs als het configuratiebestand de standaardinstelling aangeeft
zo.

--volledige index
Laat in plaats van het eerste handjevol tekens de volledige pre- en post-image-blob zien
objectnamen op de "index"-regel bij het genereren van uitvoer in patchformaat.

--binair
Voer naast --full-index een binaire diff uit die kan worden toegepast met git-apply.

--afkorting[= ]
In plaats van de volledige hexadecimale objectnaam van 40 bytes in diff-raw-indeling weer te geven
en diff-tree kopregels tonen slechts een gedeeltelijk voorvoegsel. Dit is onafhankelijk van de
--full-index optie hierboven, die het diff-patch uitvoerformaat bestuurt. Niet standaard
aantal cijfers kan worden opgegeven met --abbrev= .

-B[ ][/ ], --break-rewrites[=[ ][/ ]]
Verdeel volledige herschrijfwijzigingen in paren van verwijderen en maken. Dit serveert twee
doeleinden:

Het beïnvloedt de manier waarop een wijziging plaatsvindt die neerkomt op een totale herschrijving van een bestand en niet als een serie
van verwijderen en invoegen gemengd met een paar regels die toevallig overeenkomen
tekstueel als de context, maar als een enkele verwijdering van al het oude gevolgd door a
enkele invoeging van al het nieuwe, en het getal m bepaalt dit aspect van de -B
optie (standaard ingesteld op 60%). -B/70% specificeert dat minder dan 30% van het origineel zou moeten zijn
in het resultaat blijven zodat Git het als een totale herschrijving kan beschouwen (dat wil zeggen, anders wordt de
de resulterende patch zal een reeks verwijderingen en invoegingen zijn, vermengd met context
lijnen).

Bij gebruik met -M wordt een volledig herschreven bestand ook beschouwd als de bron van een
hernoemen (meestal beschouwt -M alleen een verdwenen bestand als de bron van een hernoeming),
en het getal n regelt dit aspect van de optie -B (standaard ingesteld op 50%). -B20%
specificeert dat een verandering met toevoeging en verwijdering vergeleken met 20% of meer van de
bestandsgrootte komen in aanmerking om te worden opgepikt als mogelijke bron voor een hernoeming
een ander bestand.

-M[ ], --vind-renames[= ]
Hernoemingen detecteren. Als n is opgegeven, is dit een drempelwaarde voor de gelijkenis-index (dwz
aantal toevoegingen/verwijderingen vergeleken met de bestandsgrootte). -M90% betekent bijvoorbeeld
Git zou een verwijder/toevoeg-paar moeten beschouwen als een hernoeming als het meer dan 90% van het bestand betreft
is niet veranderd. Zonder %-teken moet het getal gelezen worden als een breuk, met a
decimaalteken ervoor. Dat wil zeggen: -M5 wordt 0.5 en is dus hetzelfde als -M50%.
Op dezelfde manier is -M05 hetzelfde als -M5%. Gebruik -M100% om de detectie te beperken tot exacte hernoemingen.
De standaardovereenkomstindex is 50%.

-C[ ], --vind-kopieën[= ]
Detecteer zowel kopieën als hernoemingen. Zie ook --vind-kopieën-harder. Als n is opgegeven, is het
heeft dezelfde betekenis als voor -M .

--kopieën-vinden-moeilijker
Om prestatieredenen vindt de optie -C standaard alleen kopieën van het originele bestand
van de kopie is gewijzigd in dezelfde wijzigingenset. Deze vlag zorgt ervoor dat het commando wordt geïnspecteerd
ongewijzigde bestanden als kandidaten voor de bron van de kopie. Dit is een zeer dure
gebruik voor grote projecten, dus gebruik het met voorzichtigheid. Meer dan één -C-optie geven
heeft hetzelfde effect.

-D, --onomkeerbaar-verwijderen
Laat de voorafbeelding weg voor verwijderingen, dwz druk alleen de koptekst af, maar niet het verschil tussen de
preimage en /dev/null. De resulterende patch is niet bedoeld om te worden aangebracht met patch of
git toepassen; dit is uitsluitend bedoeld voor mensen die zich alleen willen concentreren op het beoordelen van de
tekst na de wijziging. Bovendien ontbreekt het de uitvoer duidelijk aan voldoende informatie
pas een dergelijke patch omgekeerd toe, zelfs handmatig, vandaar de naam van de optie.

Wanneer u het samen met -B gebruikt, laat dan ook de voorafbeelding weg in het verwijderingsgedeelte van a
paar verwijderen/maken.

-l
De opties -M en -C vereisen O(n^2) verwerkingstijd waarbij n het aantal is
potentiële hernoem/kopieerdoelen. Deze optie voorkomt dat de hernoemings-/kopieerdetectie wordt uitgevoerd
als het aantal hernoemings-/kopieerdoelen het opgegeven aantal overschrijdt.

-O
Voer de patch uit in de volgorde die is opgegeven in het , die één shell-glob heeft
patroon per lijn. Dit overschrijft de configuratievariabele diff.orderFile (zie git-
config(1)). Gebruik -O/dev/null om diff.orderFile te annuleren.

-een tekst
Behandel alle bestanden als tekst.

--negeer-ruimte-op-eol
Negeer wijzigingen in de witruimte bij EOL.

-b, --negeer-ruimte-verandering
Negeer veranderingen in de hoeveelheid witruimte. Dit negeert de witruimte aan het einde van de regel, en
beschouwt alle andere reeksen van een of meer witruimtetekens als gelijkwaardig.

-w, --negeer-alle-spatie
Negeer witruimte bij het vergelijken van lijnen. Dit negeert verschillen, zelfs als één regel dat wel heeft
witruimte waar de andere regel geen ruimte heeft.

--negeer-lege-regels
Negeer wijzigingen waarvan de regels allemaal leeg zijn.

--inter-hunk-context=
Toon daarbij de context tussen diff-hunks, tot het opgegeven aantal regels
samensmeltende hunks die dicht bij elkaar staan.

-W, --functie-context
Toon hele omringende functies van veranderingen.

--ext-diff
Sta toe dat een externe diff-helper wordt uitgevoerd. Als u een externe diff-driver instelt met
gitattributen(5), u moet deze optie gebruiken git-log(1) en vrienden.

--geen-ext-diff
Externe diff-stuurprogramma's niet toestaan.

--textconv, --no-textconv
Toestaan ​​(of niet toestaan) dat externe tekstconversiefilters worden uitgevoerd bij het vergelijken van binaire bestanden
bestanden. Zien gitattributen(5) voor details. Omdat textconv-filters doorgaans a
eenrichtingsconversie, het resulterende verschil is geschikt voor menselijke consumptie, maar kan dat niet
worden toegepast. Om deze reden zijn textconv-filters standaard alleen ingeschakeld voor git-
diff(1) en git-log(1), maar niet voor git-formaat-patch(1) of diff-loodgietersopdrachten.

--ignore-submodules[= ]
Negeer wijzigingen in submodules bij het genereren van diffs. kan "geen" zijn,
"untracked", "dirty" of "all", wat de standaard is. Als u "geen" gebruikt, wordt rekening gehouden met de
submodule gewijzigd wanneer deze niet-bijgehouden of gewijzigde bestanden of de HEAD ervan bevat
verschilt van de vastgelegde commit in het superproject en kan worden gebruikt om elke commit te overschrijven
instellingen van de negeren optie git-config(1) of gitmodules(5). Wanneer "untracked" is
gebruikte submodules worden niet als vies beschouwd als ze alleen niet-getrackte inhoud bevatten (maar
ze worden nog steeds gescand op gewijzigde inhoud). Het gebruik van "dirty" negeert alle wijzigingen in het
werkboom van submodules, er zijn alleen wijzigingen in de commits opgeslagen in het superproject
getoond (dit was het gedrag tot 1.7.0). Als u "alles" gebruikt, worden alle wijzigingen verborgen
ondermodules.

--src-voorvoegsel=
Toon het opgegeven bronvoorvoegsel in plaats van "a/".

--dst-voorvoegsel=
Toon het opgegeven bestemmingsvoorvoegsel in plaats van "b/".

--geen-voorvoegsel
Toon geen bron- of bestemmingsvoorvoegsel.

Voor meer gedetailleerde uitleg over deze veel voorkomende opties, zie ook gitdiffcore(7).

-
Bereid patches voor vanaf de bovenkant pleegt.

-O , --output-directory
Gebruik om de resulterende bestanden op te slaan, in plaats van de huidige werkmap.

-n, --genummerd
Naam uitvoer in [LAPJE n/m] formaat, zelfs met een enkele patch.

-N, --ongenummerd
Naam uitvoer in [LAPJE] formaat.

--startnummer
Begin met het nummeren van de patches op in plaats van 1.

--genummerde bestanden
Namen van uitvoerbestanden zijn een eenvoudige nummerreeks zonder de standaard eerste regel van
de commit toegevoegd.

-k, --houd-onderwerp
Niet strippen/toevoegen [LAPJE] vanaf de eerste regel van het commit-logboekbericht.

-s, --aftekening
Voeg Signed-off-by: regel toe aan het commit-bericht, met behulp van de committer-identiteit van
jezelf. Zie de afmeldoptie in git-commit(1) voor meer informatie.

--stdout
Druk alle commits af naar de standaarduitvoer in mbox-formaat, in plaats van een bestand te maken
voor elke.

--bijvoegen[= ]
Maak een meerdelige/gemengde bijlage, waarvan het eerste deel het commit-bericht is en
de patch zelf in het tweede deel, met Content-Disposition: bijlage.

--geen bijlage
Schakel het maken van een bijlage uit, waarbij de configuratie-instelling wordt overschreven.

--inline[= ]
Maak een meerdelige/gemengde bijlage, waarvan het eerste deel het commit-bericht is en
de patch zelf in het tweede deel, met Content-Disposition: inline.

--draad[= ], --no-thread
Beheert de toevoeging van de headers In-Reply-To en References om de tweede en
daaropvolgende e-mails verschijnen als antwoorden op de eerste. Controleert ook het genereren van de
Message-Id-header om naar te verwijzen.

De optionele argument can be either shallow or deep. ondiep draadsnijden maakt
elke mail een antwoord op het hoofd van de serie, waarbij het hoofd uit de omslag wordt gekozen
brief, de --in-reply-to en de eerste patchmail, in deze volgorde. deep threading
maakt van elke mail een antwoord op de vorige.

De standaardwaarde is --no-thread, tenzij de formaat.thread configuratie is ingesteld. Als --thread
is opgegeven zonder stijl, wordt standaard de stijl opgegeven door formaat.thread if
geen, of anders ondiep.

Houd er rekening mee dat de standaardinstelling voor git e-mail verzenden is om e-mails zelf te versturen. Als je git wilt
format-patch om voor threading te zorgen, wilt u er zeker van zijn dat threading dat ook is
uitgeschakeld voor git send-e-mail.

--in-reply-to=Bericht-ID
Laat de eerste mail (of alle mails met --no-thread) verschijnen als een antwoord op het gegeven
Message-Id, waarmee wordt voorkomen dat threads worden verbroken om een ​​nieuwe patchreeks te bieden.

--negeer-als-in-upstream
Voeg geen patch toe die overeenkomt met een commit .. . Dit zal onderzoeken
alle patches bereikbaar vanaf maar niet van en vergelijk ze met de
patches die worden gegenereerd, en elke patch die daarmee overeenkomt, wordt genegeerd.

--onderwerp-voorvoegsel=
In plaats van de standaard [LAPJE] voorvoegsel in de onderwerpregel, gebruik in plaats daarvan
[ ]. Dit maakt een bruikbare naamgeving van een patchreeks mogelijk, en dat kan ook
gecombineerd met de optie --genummerd.

-v , --reroll-count=
Markeer de serie als de -de iteratie van het onderwerp. De uitvoerbestandsnamen hebben v
ervoor gezet, en het onderwerpvoorvoegsel ("PATCH" standaard, maar configureerbaar via
de --subject-prefix optie) heeft ` v ' eraan toegevoegd. Bijvoorbeeld --reroll-count=4 mei
maak een v4-0001-add-makefile.patch-bestand met de tekst "Onderwerp: [PATCH v4 1/20] Toevoegen
makefile" erin.

--naar=
Voeg een Aan:-header toe aan de e-mailheaders. Dit is een aanvulling op eventuele geconfigureerde headers,
en kan meerdere keren gebruikt worden. De genegeerde vorm --no-to verwijdert alle To: headers
tot nu toe toegevoegd (vanaf de configuratie- of opdrachtregel).

--cc=
Voeg een Cc:-header toe aan de e-mailheaders. Dit is een aanvulling op eventuele geconfigureerde headers,
en kan meerdere keren gebruikt worden. De ontkende vorm --no-cc verwijdert alle Cc: headers
tot nu toe toegevoegd (vanaf de configuratie- of opdrachtregel).

--van, --van=
Gebruik ident in de From:-header van elke commit-e-mail. Als de auteur de commit
is tekstueel niet identiek aan de opgegeven ident, plaats dan een From:-header in de hoofdtekst van
het bericht met de oorspronkelijke auteur. Als er geen ident is opgegeven, gebruik dan de committer ident.

Houd er rekening mee dat deze optie alleen nuttig is als u de e-mails ook daadwerkelijk verzendt en wilt
om jezelf te identificeren als de afzender, maar de originele auteur te behouden (en git am will
pak de in-body header correct op). Merk ook op dat git send-email al afhandelt
deze transformatie voor u, en deze optie mag niet worden gebruikt als u de
resultaat naar git send-e-mail.

--add-header=
Voeg een willekeurige header toe aan de e-mailheaders. Dit is een aanvulling op eventuele geconfigureerde
headers, en kan meerdere keren worden gebruikt. Bijvoorbeeld --add-header="Organisatie:
git-foo". De ontkende vorm --no-add-header wordt weggegooid allen (To:, Cc: en aangepaste) headers
tot nu toe toegevoegd vanaf de configuratie- of opdrachtregel.

--[geen-]sollicitatiebrief
Genereer naast de patches een begeleidend briefbestand met de vestiging
beschrijving, shortlog en de algemene diffstat. U kunt een beschrijving invullen in de
bestand voordat u het verzendt.

--notities[= ]
Voeg de aantekeningen toe (zie git-opmerkingen(1)) voor de commit na de drie streepjeslijn.

Het verwachte gebruiksscenario hiervan is het schrijven van ondersteunende uitleg voor de commit die
behoort niet tot het eigenlijke commit-logboekbericht en voegt het bij de patch
dwang. Terwijl je deze uitleg eenvoudig kunt schrijven nadat format-patch is uitgevoerd
maar voordat je ze verzendt, kun je ze bewaren zoals Git-notities het mogelijk maken om ze tussendoor te bewaren
versies van de patchserie (maar zie de bespreking van de notes.rewrite
configuratieopties in git-opmerkingen(1) om deze workflow te gebruiken).

--[geen]-handtekening=
Voeg een handtekening toe aan elk geproduceerd bericht. Per RFC 3676 wordt de handtekening gescheiden
het lichaam door een lijn met '--' erop. Als de handtekeningoptie wordt weggelaten, wordt de handtekening uitgevoerd
standaard ingesteld op het Git-versienummer.

--handtekeningbestand=
Werkt hetzelfde als --signature, behalve dat de handtekening uit een bestand wordt gelezen.

--achtervoegsel=.
In plaats van .patch als achtervoegsel voor gegenereerde bestandsnamen te gebruiken, gebruikt u het opgegeven achtervoegsel. A
gebruikelijk alternatief is --suffix=.txt. Als u dit leeg laat, wordt het achtervoegsel .patch verwijderd.

Merk op dat het hoofdpersonage geen punt hoeft te zijn; je kunt er bijvoorbeeld gebruik van maken
--suffix=-patch om 0001-beschrijving-van-mijn-wijzigingspatch te verkrijgen.

-q, --stil
Druk de namen van de gegenereerde bestanden niet af naar de standaarduitvoer.

--niet-binair
Voer geen inhoud van wijzigingen in binaire bestanden uit, maar geef in plaats daarvan een melding weer dat deze
bestanden gewijzigd. Patches die met deze optie zijn gegenereerd, kunnen niet correct worden toegepast, maar
ze zijn nog steeds nuttig voor codebeoordeling.

--nul-commit
Voer een geheel-nul-hash uit in de From-header van elke patch in plaats van de hash van de commit.

--wortel
Behandel het revisieargument als een , ook al is het maar één commit
(dat normaal gesproken wordt behandeld als een ). Houd er rekening mee dat root-commits zijn opgenomen in de
het opgegeven bereik worden altijd opgemaakt als creatiepatches, onafhankelijk van deze vlag.

CONFIGURATIE

U kunt extra regels voor de e-mailkop opgeven die aan elk bericht moeten worden toegevoegd, standaardwaarden voor de
onderwerpvoorvoegsel en bestandsachtervoegsel, patchnummers bij uitvoer van meer dan één patch, toevoegen
'Aan' of 'Cc:' headers, configureer bijlagen en teken patches af met configuratie
variabelen.

[formaat]
headers = "Organisatie: git-foo\n"
subjectPrefix = WIJZIG
achtervoegsel = .txt
genummerd = automatisch
naar =
cc =
bijlage [ = mime-grens-string ]
afmelden = waar
sollicitatiebrief = auto

DISCUSSIE

De patch geproduceerd door git formaat-patch is in UNIX-mailboxformaat, met een vaste "magie"
tijdstempel om aan te geven dat het bestand wordt uitgevoerd vanuit format-patch in plaats van een real
brievenbus, zo:

From 8f72bad1baf19a53459661343e21d6491c3908d3 Mon Sep 17 00:00:00 2001
Van: Tony Geluk[e-mail beveiligd]>
Datum: dinsdag 13 juli 2010 11:42:54 -0700
Subject: [PATCH] =?UTF-8?q?[IA64]=20Put=20ia64=20config=20files=20on=20the=20?=
=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig=20diet?=
MIME-Version: 1.0
Inhoudstype: tekst/gewoon; tekenset=UTF-8
Inhoud-overdracht-codering: 8bit

arch/arm-configuratiebestanden werden afgeslankt met behulp van een Python-script
(See commit c2330e286f68f1c408b4aa6515ba49d57f05beae comment)

Doe hetzelfde voor ia64, zodat we er strak en strak uit kunnen zien
...

Normaal gesproken wordt het in de conceptmap van een MUA geplaatst, bewerkt om er tijdig commentaar aan toe te voegen
mag niet na de drie streepjes in de changelog komen en vervolgens als bericht worden verzonden waarvan
body begint in ons voorbeeld met "arch/arm configuratiebestanden waren...". Aan de ontvangende kant,
lezers kunnen interessante patches opslaan in een UNIX-mailbox en deze toepassen git-am(1).

Wanneer een patch deel uitmaakt van een lopende discussie, wordt de patch gegenereerd door git formaat-patch blikje
worden aangepast om te profiteren van de git am --schaar functie. Na uw reactie op de
discussie komt een regel die uitsluitend bestaat uit "-->8 --" (schaar en perforatie),
gevolgd door de patch waarbij onnodige headervelden zijn verwijderd:

...
> Dus we moeten zus en zo doen.

Lijkt me logisch. Hoe zit het met dit pleistertje?

-- >8 --
Onderwerp: [IA64] Zet ia64-configuratiebestanden op het Uwe Kleine-König-dieet

arch/arm-configuratiebestanden werden afgeslankt met behulp van een Python-script
...

Wanneer u op deze manier een patch verzendt, verzendt u meestal uw eigen patch, dus daarnaast
naar de markering "From $SHA1 $magic_timestamp" moet u de regels From: en Date: weglaten uit de
patchbestand. De titel van de patch zal waarschijnlijk verschillen van het onderwerp van de discussie
de patch is een reactie op, dus het is waarschijnlijk dat u het onderwerp wilt behouden:
lijn, zoals in het bovenstaande voorbeeld.

Controleren voor stuk corruptie
Veel mailers zullen, als ze niet goed zijn ingesteld, de witruimte beschadigen. Hier zijn twee veel voorkomende soorten
corruptie:

· Lege contextregels die dat niet hebben elke witte ruimte.

· Niet-lege contextregels die aan het begin één extra witruimte hebben.

Een manier om te testen of uw MUA correct is ingesteld, is:

· Stuur de patch naar uzelf, precies zoals u dat zou doen, behalve met de regels To: en Cc:
die niet de lijst en het adres van de beheerder bevatten.

· Sla die patch op in een bestand in UNIX-mailboxformaat. Noem het bijvoorbeeld een patch.

· Het toepassen:

$ git ophalen master: proef toepassen
$ git checkout test toepassen
$ git reset --hard
$ git ben een.patch

Als het niet correct van toepassing is, kunnen daar verschillende redenen voor zijn.

· De pleister zelf is niet netjes aan te brengen. Dat is slecht maar heeft er niet zoveel mee te maken
jouw MUA. Misschien wil je de patch opnieuw baseren git-rebase(1) voordat u het regenereert
in dit geval.

· De MUA heeft uw patch beschadigd; "am" zou klagen dat de patch niet van toepassing is. Kijk
in de .git/rebase-apply/ submap en kijk wat stuk bestand bevat en controleert
de hierboven genoemde algemene corruptiepatronen.

· Terwijl u bezig bent, controleert u de info en definitieve verbintenis bestanden ook. Als wat erin zit definitieve verbintenis
niet precies is wat u zou willen zien in het commit log bericht, het is zeer waarschijnlijk
dat de ontvanger het logbericht uiteindelijk met de hand zou bewerken bij het toepassen van uw patch.
Dingen als "Hallo, dit is mijn eerste patch.\n" in de patch-e-mail moeten na de
lijn met drie streepjes die het einde van het commit-bericht aangeeft.

MUA-SPECIFIEK TIPS

Hier volgen enkele tips over hoe u met succes patches inline kunt indienen met behulp van verschillende mailers.

GMail
Gmail heeft geen enkele manier om regelterugloop in de webinterface uit te schakelen, dus dat zal wel gebeuren
alle e-mails die u verzendt, verminken. Je kunt echter "git send-email" gebruiken en je
patches via de Gmail SMTP-server, of gebruik een IMAP-e-mailclient om verbinding te maken met de
google IMAP-server en stuur de e-mails daardoor door.

Voor tips over het gebruik git e-mail verzenden om uw patches via de Gmail SMTP-server te verzenden, zie
het VOORBEELD-gedeelte van git-send-e-mail(1).

Voor tips over indiening via de IMAP-interface, zie het VOORBEELD-gedeelte van git-imap-
nieuwsbrieven(1).

Thunderbird
Standaard verpakt Thunderbird e-mails en markeert deze ook als zijnde format=stroomde,
beide zullen de resulterende e-mail onbruikbaar maken voor Git.

Er zijn drie verschillende benaderingen: gebruik een add-on om regelafbrekingen uit te schakelen, configureer
Thunderbird om patches niet te verminken, of een externe editor te gebruiken om Thunderbird ervan te weerhouden
het verminken van de pleisters.

Aanpak #1 (toevoeging)
Installeer de Toggle Word Wrap-add-on die beschikbaar is vanaf
https://addons.mozilla.org/thunderbird/addon/toggle-word-wrap/ Het voegt een menu-item toe
"Word Wrap inschakelen" in het menu "Opties" van de componist, dat u kunt aanvinken. Nu kan je
stel het bericht op zoals u dat anders doet (knippen + plakken, git formaat-patch | git
imap-verzenden, enz.), maar u moet regeleinden handmatig invoegen in elke tekst die u gebruikt
type.

Aanpak #2 (configuratie)
Drie stappen:

1. Configureer de samenstelling van uw mailserver als platte tekst: Bewerken...Account
Instellingen...Compositie en adressering, verwijder het vinkje bij "Berichten opstellen in HTML".

2. Configureer uw algemene compositievenster zo dat er geen omloop is.

In Thunderbird 2: Bewerken..Voorkeuren..Compositie plaatst u platte tekstberichten op 0

In Thunderbird 3: Bewerken..Voorkeuren..Geavanceerd..Config-editor. Zoeken
"mail.wrap_long_lines". Schakel deze in om er zeker van te zijn dat deze is ingesteld op false. Zoek ook
voor "mailnews.wraplength" en stel de waarde in op 0.

3. Schakel het gebruik van format=flowed uit: Edit..Preferences..Advanced..Config Editor.
Zoek naar "mailnews.send_plaintext_flowed". Schakel deze in om er zeker van te zijn dat deze is ingesteld op
vals.

Nadat dat is gebeurd, zou u e-mail moeten kunnen opstellen zoals u dat anders zou doen (knippen +
pasta, git formaat-patch | git imap-verzenden, etc), en de patches zullen niet verminkt worden.

Aanpak #3 (extern editor)
De volgende Thunderbird-extensies zijn nodig: AboutConfig from
http://aboutconfig.mozdev.org/ en Externe Editor van
http://globs.org/articles.php?lng=nl&pg=8

1. Bereid de patch voor als tekstbestand met behulp van de door u gekozen methode.

2. Voordat u een opstelvenster opent, gebruikt u Bewerken → Accountinstellingen om het vinkje bij "Opstellen
berichten in HTML-indeling" in het paneel "Samenstelling en adressering" van het
account dat moet worden gebruikt om de patch te verzenden.

3. In het hoofdvenster van Thunderbird: vaardigheden je opent het opstelvenster voor de patch,
gebruik Tools → about:config om het volgende in te stellen op de aangegeven waarden:

mailnews.send_plaintext_flowed => onwaar
mailnieuws.wraplengte => 0

4. Open een opstelvenster en klik op het externe editorpictogram.

5. Lees in het externe editorvenster het patchbestand in en sluit de editor af
normaal gesproken.

Kanttekening: het is misschien mogelijk om stap 2 uit te voeren met about:config en het volgende
instellingen, maar nog niemand heeft het geprobeerd.

mail.html_compose => onwaar
mail.identity.default.compose_html => onwaar
mail.identity.id?.compose_html => false

Er is een script in contrib/thunderbird-patch-inline dat u kan helpen dit op te nemen
patches met Thunderbird op een eenvoudige manier. Om het te gebruiken, voert u de bovenstaande stappen uit en gebruikt u vervolgens
het script als de externe editor.

KMail
Dit zou u moeten helpen bij het inline indienen van patches met KMail.

1. Bereid de patch voor als tekstbestand.

2. Klik op Nieuwe e-mail.

3. Ga onder "Opties" in het Composer-venster en zorg ervoor dat "Woordomloop" niet is ingesteld.

4. Gebruik Bericht → Bestand invoegen... en voeg de patch in.

5. Terug in het opstelvenster: voeg de gewenste tekst toe aan het bericht, voltooi het
de adres- en onderwerpvelden en druk op verzenden.

Voorbeelden

· Extraheer commits tussen revisies R1 en R2, en pas ze toe bovenop de huidige
tak gebruikt git am om ze uit te kiezen:

$ git format-patch -k --stdout R1..R2 | git ben -3 -k

· Extraheer alle commits die zich in de huidige branch bevinden, maar niet in de origin branch:

$ git formaat-patch oorsprong

Voor elke commit wordt een apart bestand aangemaakt in de huidige map.

· Extraheer alle commits die leiden tot herkomst sinds de start van het project:

$ git format-patch --root oorsprong

· Hetzelfde als de vorige:

$ git format-patch -M -B oorsprong

Bovendien detecteert en verwerkt het op intelligente wijze hernoemingen en volledige herschrijvingen
een hernoemingspatch produceren. Een hernoemingspatch vermindert de hoeveelheid tekstuitvoer, en
maakt het over het algemeen gemakkelijker om te beoordelen. Merk op dat niet-Git "patch" programma's dat niet doen
begrijp het hernoemen van patches, dus gebruik het alleen als je weet dat de ontvanger Git gebruikt
breng uw pleister aan.

· Haal de drie bovenste commits uit de huidige branch en formatteer ze als e-mailbaar
pleisters:

$ git formaat-patch -3

Gebruik git-format-patch online met behulp van onworks.net-services