Data som följer efter nyckelordet gitdir och ett kolon används som ett glob-mönster. Om platsen för .git-katalogen matchar mönstret är include-villkoret uppfyllt.

Det här är samma sak som gitdir förutom att matchningen görs skiftlägesoberoende (t.ex. på filsystem som är skiftlägesoberoende)

Data som följer nyckelordet onbranch och ett kolon tas som ett mönster med vanliga globbing-jokertecken och två ytterligare, **/ och /**, som kan matcha flera sökvägskomponenter. Om vi befinner oss i ett arbetsträd där namnet på den gren som för närvarande är utcheckad matchar mönstret, är include-villkoret uppfyllt.

Data som följer efter detta nyckelord och ett kolon tas som ett mönster med vanliga globbing-jokertecken och två ytterligare, **/ och /**, som kan matcha flera komponenter. Första gången detta nyckelord ses kommer resten av konfigurationsfilerna att skannas efter fjärr-URL:er (utan att tillämpa några värden). Om det finns minst en fjärr-URL som matchar detta mönster är inkluderingsvillkoret uppfyllt.

När en variabel sägs anta ett booleskt värde accepteras många synonymer för sant och falskt; dessa är alla skiftlägesoberoende.

Värdet för många variabler som anger olika storlekar kan ges suffix med k, M,…​ för att betyda "skala talet med 1024", "med 1024x1024", etc.

Värdet för en variabel som tar en färg är en lista med färger (högst två, en för förgrund och en för bakgrund) och attribut (så många du vill), separerade med mellanslag.

En variabel som tar ett sökvägsvärde kan ges en sträng som börjar med "~/" eller "~user/", och den vanliga tilde-expansionen sker för en sådan sträng: ~/ expanderas till värdet $HOME och ~user/ till den angivna användarens hemkatalog.

Anger att git add ska fortsätta lägga till filer när vissa filer inte kan läggas till på grund av indexeringsfel. Motsvarar alternativet --ignore-errors i git-add[1]. add.ignore-errors är föråldrad eftersom den inte följer den vanliga namngivningskonventionen för konfigurationsvariabler.

Anger för git branch, git switch och git checkout att ställa in nya grenar så att git-pull[1] sammanslås korrekt från startpunktsgrenen. Observera att även om detta alternativ inte är angivet kan detta beteende väljas per gren med hjälp av alternativen --track och --no-track. Standardinställningen för detta alternativ är true. De giltiga inställningarna är:

När en ny gern skapas med git branch, git switch eller git checkout som spårar en annan gren, talar denna variabel om för Git att ställa in pull för att obasera istället för sammanslå (se branch.<name>.rebase). De giltiga inställningarna är:

Denna variabel styr sorteringsordningen för grenar när de visas av git-branch[1]. Utan alternativet --sort=<värde> kommer värdet för denna variabel att användas som standard. Se fältnamnen i git-for-each-ref[1] för giltiga värden.

När den är på grenen <namn>, talar den om för git fetch och git push vilken fjärr som ska hämtas från eller pushas till. Fjärren som pushas till kan åsidosättas med remote.pushDefault (för alla grenar). Fjärren som pushas till, för den aktuella grenen, kan ytterligare åsidosättas av branch.<namn>.pushRemote. Om ingen fjärr är konfigurerad, eller om du inte är på någon gren och det finns mer än en fjärr definierad i förvaret, används som standard origin för hämtning och remote.pushDefault för push:ing. Dessutom är . (en punkt) det aktuella lokala förvaret (ett punkt-förvar), se `branch.<namn>.merge`s sista anmärkning nedan.

När den är på branch <name>, åsidosätter den branch.<name>.remote för push:ning. Den åsidosätter också remote.pushDefault för push:ning från gren <name>. När du hämtar från en plats (t.ex. din uppströms) och pushar till en annan plats (t.ex. ditt eget publiceringsfövar), vill du ställa in remote.pushDefault för att ange fjärren som push-funktionen ska skickas till för alla grenar, och använda det här alternativet för att åsidosätta det för en specifik gren.

Definierar, tillsammans med branch.<namn>.remote, uppströmsgrenen för den givna grenen. Den anger för git fetch/git pull/git rebase vilken gren som ska sammanslås och kan också påverka git push (se push.default). I grenen <namn> anger den för git fetch vilken standardrefspec som ska markeras för sammanfogning i FETCH_HEAD. Värdet hanteras som den fjärr-delen av en refspec och måste matcha en ref som hämtas från fjärren som anges av branch.<namn>.remote. Sammanslagnings-informationen används av git pull (som först anropar git fetch) för att söka efter standardgrenen för sammanfogning. Utan detta alternativ sammanslår git pull som standard den första hämtade refspecen. Ange flera värden för att få en bläckfisk-sammanfogning. Om du vill konfigurera git pull så att den sammanfogas med <namn> från en annan gren i det lokala arkivet, kan du peka branch.<namn>.merge till önskad gren och använda den relativa sökvägsinställningen . (en punkt) för branch.<namn>.remote.

Ställer in standardalternativ för sammanslagning till grenen <namn>. Syntaxen och de alternativ som stöds är desamma som för git-merge[1], men alternativvärden som innehåller blanksteg stöds för närvarande inte.

När det är sant, ombasera grenen <namn> ovanpå den hämtade grenen, istället för att sammanfoga standardgrenen från standardfjärren när git pull körs. Se pull.rebase för att göra detta på ett icke-grenspecifikt sätt.

Grenbeskrivning, kan redigeras med git branch --edit-description. Grenbeskrivningen läggs automatiskt till i format-patch följebrevet eller request-pull sammanfattningen.

När du kör git checkout <något> eller git switch <något> och bara har en fjärr, kan den implicit återgå till att checka ut och spåra, t.ex. origin/<något>. Detta slutar fungera så fort du har mer än en fjärr med en <något>-referens. Den här inställningen gör det möjligt att ställa in namnet på en föredragen fjärr som alltid ska vinna vid särskiljning. Det typiska användningsfallet är att ställa in detta till origin.

Anger standardvärdet för alternativen --guess eller --no-guess i git checkout och git switch. Se git-switch[1] och git-checkout[1].

Antalet parallella arbetare som ska användas vid uppdatering av arbetskatalogen. Standardvärdet är ett, dvs. sekventiell exekvering. Om det sätts till ett värde mindre än ett, kommer Git att använda lika många arbetare som antalet tillgängliga logiska kärnor. Denna inställning och checkout.thresholdForParallelism påverkar alla kommandon som utför utcheckning. T.ex. checkout, clone, reset, sparse-checkout, etc.

När man kör parallell utcheckning med ett litet antal filer kan kostnaden för att skapa underprocesser och kommunikation mellan processer överväga vinsterna med parallellisering. Den här inställningen låter dig definiera det minsta antalet filer som parallell utcheckning ska försökas för. Standardinställningen är 100.

Namnet på den fjärren som ska skapas vid kloning av ett arkiv. Standardvärdet är origin. Den kan åsidosättas genom att skicka kommandoradsalternativet --origin till git-clone[1].

Avvisa kloning av ett kodförråd om det är ett ytligt sådant; detta kan åsidosättas genom att skicka alternativet --reject-shallow på kommandoraden. Se git-clone[1].

Om ett partiellt klonfilter tillhandahålls (se --filter i git-rev-list[1]) och --recurse-submodules används, använd även filtret på undermoduler.

Den här inställningen åsidosätter standardinställningen för --cleanup-alternativet i git commit. See git-commit[1] for details. Att ändra standardinställningen kan vara användbart när du alltid vill behålla rader som börjar med kommentartecknet (core.commentChar, standard #) i ditt loggmeddelande, i vilket fall du skulle göra git config commit.cleanup whitespace (observera att du själv måste ta bort hjälpraderna som börjar med kommentartecknet i incheckning-loggmallen om du gör detta).

En boolesk kod som anger om alla incheckningar ska GPG-signeras. Användning av det här alternativet vid operationer som ombasering kan resultera i att ett stort antal incheckningar signeras. Det kan vara praktiskt att använda en agent för att undvika att skriva in din GPG-lösenfras flera gånger.

Ett booleskt värde för att aktivera/inaktivera inkludering av statusinformation i inchecknings-meddelandemallen när en editor används för att förbereda inchecknings-meddelandet. Standardvärdet är true.

Ange sökvägen till en fil som ska användas som mall för nya inchecknings-meddelanden.

Ett booleskt värde eller ett heltal för att ange utförlighetsnivån med git commit. See git-commit[1] for details.

När du använder git diff för att jämföra med arbetsträdfiler, betrakta inte ändringar som endast innehåller statistiska data som ändrade. Kör istället git update-index --refresh i tysthet för att uppdatera den cachade statistiska informationen för sökvägar vars innehåll i arbetsträdet matchar innehållet i indexet. Standardvärdet för detta alternativ är true. Observera att detta endast påverkar git diff Porslin, och inte diff-kommandon på lägre nivå som git diff-files.

En kommaseparerad lista med --dirstat-parametrar som anger standardbeteendet för --dirstat-alternativet till git-diff[1] och vänner. Standardvärdena kan åsidosättas på kommandoraden (med --dirstat=<param>,...). Reservstandardvärdena (när de inte ändras av diff.dirstat) är changes,noncumulative,3. Följande parametrar är tillgängliga:

Begränsa bredden på filnamnsdelen i --stat-utdata. Om angivet gäller det alla kommandon som genererar --stat-utdata förutom format-patch.

Begränsa bredden på grafdelen i --stat-utdata. Om angivet gäller det alla kommandon som genererar --stat-utdata förutom format-patch.

Generera diffar med <n> rader kontext istället för standardvärdet 3. Detta värde åsidosätts av alternativet -U.

Visa sammanhanget mellan olika stycken, upp till det angivna antalet rader, och sammanfoga därmed de stycken som ligger nära varandra. Detta värde fungerar som standardvärde för kommandoradsalternativet --inter-hunk-context.

Om denna konfigurationsvariabel är satt, utförs diff-generering inte med hjälp av den interna diff-maskineriet, utan med hjälp av det givna kommandot. Kan åsidosättas med miljövariabeln GIT_EXTERNAL_DIFF. Kommandot anropas med parametrar som beskrivs under "git Diffs" i git[1]. Obs: om du bara vill använda ett externt diff-program på en delmängd av dina filer, kanske du vill använda gitattributes[5] istället.

Om detta booleska värde är satt till true förväntas kommandot diff.external returnera avslutningskoden 0 om det anser att indatafilerna är lika eller 1 om det anser att de är olika, som diff(1). Om det är satt till false, vilket är standardvärdet, förväntas kommandot returnera avslutningskoden 0 oavsett likhet. All annan avslutningskod gör att Git rapporterar ett allvarligt fel.

Ställer in standardvärdet för --ignore-submodules. Observera att detta endast påverkar git diff Porslin, och inte lägre nivåer av diff-kommandon som git diff-files. git checkout och git switch respekterar också denna inställning vid rapportering av ej incheckade ändringar. Om den ställs in på all inaktiveras undermoduls-ammanfattningen som normalt visas av git commit och git status när status.submoduleSummary är inställt om den inte åsidosätts med hjälp av kommandoradsalternativet --ignore-submodules. Kommandona git submodule påverkas inte av denna inställning. Som standard är detta inställt på ospårad så att eventuella ej spårade undermoduler ignoreras.

Om detta är satt använder git diff ett prefixpar som skiljer sig från standard a/ och b/ beroende på vad som jämförs. När denna konfiguration är aktiv byter även omvänd diff-utmatning ordningen på prefixen:

Om angivet visar git diff inget käll- eller destinationsprefix.

Om angivet använder git diff detta källkodsprefix. Standardvärdet är a/.

Om angivet använder git diff detta destinationsprefix. Standardvärdet är b/.

Om den är satt till true visar git diff inte ändringar utanför katalogen och visar sökvägar i förhållande till den aktuella katalogen.

Fil som anger hur filer ska ordnas inom en diff. Se -O-flaggan till git-diff[1] för mer information.. Om diff.orderFile är en relativ sökväg behandlas den som relativt till toppen av arbetskatalogen.

Antalet filer som ska beaktas i den uttömmande delen av kopierings-/namnbytesdetektering; motsvarande git diffflaggan -l. Om det inte är inställt är standardvärdet för närvarande 1000. Denna inställning har ingen effekt om namnbytesdetektering är avstängd.

Om och hur Git identifierar namnbyten. Om det är satt till false är namnbytesdetektering inaktiverad. Om det är satt till true är grundläggande namnbytesdetektering aktiverad. Om det är satt till copies eller copy kommer Git även att identifiera kopior. Standardvärdet är true. Observera att detta endast påverkar git diff Porslinskommandon som git-diff[1] och git-log[1], och inte lägre kommandon som git-diff-files[1].

Ett booleskt värde för att förhindra standardbeteendet att skriva ut ett mellanslag före varje tom utdatarad. Standardvärdet är false.

Ange formatet i vilket skillnader i undermoduler visas. Formatet short visar bara namnen på incheckningar i början och slutet av intervallet. Formatet log listar incheckningar i intervallet, precis som git-submodule[1] summary gör. Formatet diff visar en inline-diff av det ändrade innehållet i undermodulen. Standardinställningen är short.

Ett utökat reguljärt uttryck i POSIX som används för att avgöra vad som är ett "ord" vid ord-för-ord-differensberäkningar. Teckensekvenser som matchar det reguljära uttrycket är "ord", alla andra tecken är ignorerbara blanksteg.

Anpassat diff förare kommando. Se gitattributes[5] för mer information.

Om detta booleska värde är satt till true förväntas kommandot diff.<förare>.command returnera avslutningskod 0 om det anser att indatafilerna är lika eller 1 om det anser att de är olika, som diff(1). Om det är satt till false, vilket är standardvärdet, förväntas kommandot returnera avslutningskod 0 oavsett likhet. All annan avslutningskod gör att Git rapporterar ett allvarligt fel.

Det reguljära uttryck som diff-föraren ska använda för att känna igen styckes-huvuden. Ett inbyggt mönster kan också användas. Se gitattributes[5] för mer information.

Sätt det här alternativet till true för att få diff-förare att behandla filer som binära. Se gitattributes[5] för mer information.

Kommandot som diff-drivrutinen ska anropa för att generera den textkonverterade versionen av en fil. Resultatet av konverteringen används för att generera en människoläsbar diff. Se gitattributes[5] för mer information.

Det reguljära uttryck som diff-drivrutinen ska använda för att dela upp ord på en rad. Se gitattributes[5] för mer information.

Sätt det här alternativet till true för att få diff-drivrutinen att cachelagra textkonverteringsutdata. Se gitattributes[5] för mer information.

Ställ in det här alternativet på false för att inaktivera standardheuristiken som flyttar olika hunk-gränser för att göra patchar lättare att läsa.

Välj en diff-algoritm. Varianterna är följande:

Markera blankteckenfel i raderna context, old eller new i diff-filen. Flera värden separeras med kommatecken, none återställer tidigare värden, default återställer listan till new och all är en förkortning för old,new,context. Blankteckenfelen är färgade med color.diff.whitespace. Kommandoradsalternativet --ws-error-highlight=<slag> åsidosätter denna inställning.

Om den är satt till antingen ett giltigt <läge> eller ett sant-värde, färgas flyttade linjer i en diff olika. För detaljer om giltiga lägen, se --color-moved i git-diff[1]. Om den bara ställs in på sant används standardfärgläget. När den ställs in på false färgas inte flyttade linjer.

När flyttade linjer färgläggs med t.ex. inställningen diff.colorMoved, styr detta alternativ läget för hur mellanslag behandlas. För detaljer om giltiga lägen, se --color-moved-ws i git-diff[1].

Det här alternativet styr om git fetch (och den underliggande hämtningen i git pull) rekursivt ska hämta till ifyllda undermoduler. Det här alternativet kan ställas in antingen på ett booleskt värde eller på on-demand. Att ställa in det på ett booleskt värde ändrar beteendet för fetch and pull så att de villkorslöst rekurserar till undermoduler när de är satta till true (sant) eller till att inte rekursera alls när de är satta till false (falskt). När de är satta till on-demand kommer fetch and pull bara att rekursera till en ifylld undermodul när dess superprojekt hämtar en commit som uppdaterar undermodulens referens. Standardvärdet är on-demand, eller till värdet för submodule.recurse om det är satt.

Om den är satt till sant kommer git-fetch-pack att kontrollera alla hämtade objekt. Se transfer.fsckObjects för vad som är markerat. Standardvärdet är false. Om det inte är satt används värdet för transfer.fsckObjects istället.

Fungerar som fsck.<medd-id>, men används av git-fetch-pack[1] istället för git-fsck[1]. Se dokumentationen för fsck.<medd-id> för mer information.

Fungerar som fsck.skipList, men används av git-fetch-pack[1] istället för git-fsck[1]. Se dokumentationen för fsck.skipList för mer information.

Om antalet objekt som hämtas via Git-överföringen understiger denna gräns, kommer objekten att packas upp till lösa objektfiler. Om antalet mottagna objekt däremot är lika med eller överstiger denna gräns, kommer det mottagna paketet att lagras som ett paket, efter att eventuella saknade deltabaser har lagts till. Att lagra paketet från en push-operation kan göra att push-operationen slutförs snabbare, särskilt på långsamma filsystem. Om det inte är angivet används värdet transfer.unpackLimit istället.

Om sant, kommer fetch automatiskt att bete sig som om --prune-alternativet angavs på kommandoraden. Se även remote.<namn>.prune och BESKÄRNING-sektionen i git-fetch[1].

Om sant, kommer fetch automatiskt att bete sig som om refs/tags/*:refs/tags/* refspec angavs vid beskärning, om den inte redan är angiven. Detta gör det möjligt att ställa in både detta alternativ och fetch.prune för att bibehålla en 1=1-mappning till uppströmsreferenser. Se även remote.<namn>.pruneTags och BESKÄRNING-sektionen i git-fetch[1].

Om sant, kommer fetch att försöka uppdatera alla tillgängliga fjärrar. Detta beteende kan åsidosättas genom att skicka --no-all eller genom att explicit ange en eller flera fjärrar att hämta från. Standardvärdet är false.

Styr hur referensuppdateringsstatus skrivs ut. Giltiga värden är full och compact. Standardvärdet är full. Se avsnittet UTMATNING i git-fetch[1] för mer information.

Styr hur information om incheckningar i det lokala förvaret skickas vid förhandling av innehållet i packfilen som ska skickas av servern. Ställ in på consecutive för att använda en algoritm som går över på varandra följande incheckningar och kontrollerar var och en. Ställ in på skipping för att använda en algoritm som hoppar över incheckningar i ett försök att konvergera snabbare, men kan resultera i en packfil som är större än nödvändigt; eller sätt på noop för att inte skicka någon information alls, vilket nästan säkert kommer att resultera i en packfil som är större än nödvändigt, men som hoppar över förhandlingssteget. Ställ in på default för att åsidosätta inställningar som gjorts tidigare och använda standardbeteendet. Standardvärdet är normalt consecutive, men om feature.experimental är true är standardvärdet skipping. Okända värden kommer att orsaka att git fetch ger fel.

Sätt till false för att aktivera --no-show-forced-updates i kommandona git-fetch[1] och git-pull[1]. Standardvärdet är true.

Anger det maximala antalet hämtningsoperationer som ska köras parallellt samtidigt (undermoduler eller fjärrar när --multiple-alternativet i git-fetch[1] är aktivt).

Sätt till true för att skriva en inchecknings-graph efter varje git fetch-kommando som laddar ner en pack-fil från en fjärr. Med alternativet --split skapar de flesta körningar en mycket liten inchecknings-graph-fil ovanpå den/de befintliga inchecknings-graph-filen/filerna. Ibland slås dessa filer samman och skrivningen kan ta längre tid. Att ha en uppdaterad inchecknings-graph-fil hjälper till att utföra många Git-kommandon, inklusive git merge-base, git push -f och git log --graph. Standardvärdet är false.

Det här värdet lagrar en URI för att ladda ner Git-objektdata från en bunt-URI innan en stegvis hämtning utförs från den ursprungliga Git-servern. Detta liknar hur alternativet --bundle-uri beter sig i git-clone[1]. git clone --bundle-uri kommer att ställa in värdet fetch.bundleURI om den angivna bunt-URI:n innehåller en bunt-lista som är organiserad för stegvisa hämtningar.

När fetch.bundleURI används för att hämta stegvis från en bunt-lista som använder heuristiken "creationToken", lagrar detta konfigurationsvärde det maximala creationToken-värdet för de nedladdade buntarna. Detta värde används för att förhindra nedladdning av buntar i framtiden om den annonserade creationToken inte är strikt större än detta värde.

Ange katalogen från vilken mallarna ska kopieras. (See the "TEMPLATE DIRECTORY" section of git-init[1].)

Tillåter att åsidosätta standardgrennamnet, t.ex. vid initialisering av ett nytt kodförråd.

Tillåter att åsidosätta standardobjektformatet för nya arkiv. Se --object-format= i git-init[1]. Både kommandoradsalternativet och miljövariabeln GIT_DEFAULT_HASH har företräde framför denna konfiguration.

Tillåter åsidosättning av standardformatet för referenslagring för nya arkiv. Se --ref-format= i git-init[1]. Både kommandoradsalternativet och miljövariabeln GIT_DEFAULT_REF_FORMAT har företräde framför denna konfiguration.

Om sant, gör git-log[1], git-show[1], och git-whatchanged[1] anta --abbrev-commit. Du kan åsidosätta detta alternativ med --no-abbrev-commit.

Ställ in standardläget för datum och tid för log-kommandot. Att ställa in ett värde för log.date liknar att använda git logs --date-alternativ. Se git-log[1] för mer information.

Print out the ref names of any commits that are shown by the log command. Possible values are:

Som standard, visar git log bara dekorationer för vissa kända referensnamnrymder. Om alla anges visas alla referenser som dekorationer.

Exkludera de angivna mönstren från loggdekorationerna. Detta liknar kommandoradsalternativet --decorate-refs-exclude, men konfigurations-alternativet kan åsidosättas av --decorate-refs.

Ställ in diff-formatet som ska användas när --diff-merges=on är specificerat, se --diff-merges i git-log[1] för detaljer. Standardinställningen är separate.

Om true kommer git log att agera som om --follow-alternativet användes när en enda <sökväg> anges. Detta har samma begränsningar som --follow, d.v.s. det kan inte användas för att följa flera filer och fungerar inte bra på icke-linjär historik.

En lista med färger, separerade med kommatecken, som kan användas för att rita historiklinjer i git log --graph.

Om sant, visas den initiala incheckningen som en stor skapandehändelse. Detta motsvarar en diff mot ett tomt träd. Verktyg som git-log[1] eller git-whatchanged[1], som normalt döljer rot-incheckningen, kommer nu att visa den. Sant som standard.

Om sant, gör att git-log[1], git-show[1] och git-whatchanged[1] antar --show-signature.

Om sant, gör att git-log[1], git-show[1] och git-whatchanged[1] antar --use-mailmap, annars antar man --no-use-mailmap. Sant som standard.

Ange stilen med vilken konfliktfyllda stycken skrivs ut till arbetsträdfiler vid sammanslagning. Standardinställningen är "merge", som visar en <<<<<<< konfliktmarkör, ändringar gjorda av ena sidan, en =======-markör, ändringar gjorda av den andra sidan och sedan en >>>>>>> markör. En alternativ stil, "diff3", lägger till en |||||||| markör och originaltexten före =======-markören. Stilen "merge" tenderar att producera mindre konfliktområden än diff3, både på grund av att originaltexten utesluts och för att när en delmängd av rader matchar på de två sidorna, dras de bara ut ur konfliktområdet. En annan alternativ stil, "zdiff3", liknar diff3 men tar bort matchande rader på de två sidorna från konfliktområdet när dessa matchande rader visas nära antingen början eller slutet av ett konfliktområde.

Om merge anropas utan något inchecknings-argument, sammanfogas de uppströmsgrenar som konfigurerats för den aktuella grenen med hjälp av deras senast observerade värden som lagrats i deras fjärrspårningsgrenar. Värdena för branch.<nuvarande gren>.merge som namnger grenarna på fjärrvärd namngiven av branch.<nuvarande gren>.remote konsulteras, och sedan mappas de via remote.<fjärrvärd>.fetch till deras motsvarande fjärrspårningsgrenar, och topparna för dessa spårningsgrenar sammanfogas. Standardvärdet är sant.

Som standard, skapar Git inte en extra sammanslagnings-incheckningar när den sammanfogar en incheckning som är en underordnad till den topen av aktuell incheckning. Istället snabbspolas spetsen för den aktuella grenen framåt. När den är satt till false, talar denna variabel om för Git att skapa en extra sammanslagnings-incheckning i ett sådant fall (motsvarande att ge alternativet --no-ff från kommandoraden). När den är satt till only, tillåts endast sådana snabbspolnings-sammanslagningar (motsvarande att ge alternativet --ff-only från kommandoraden).

Om sant, motsvarar detta kommandoradsalternativet --verify-signatures. Se git-merge[1] för mer information.

Förutom grennamnen, fyll i loggmeddelandet med den grenbeskrivningstext som är associerad med dem. Standardvärdet är falskt.

Förutom grennamn, fyll i loggmeddelandet med högst det angivna antalet enradsbeskrivningar från de faktiska incheckningar som sammanfogas. Standardvärdet är falskt, och sant är en synonym för 20.

Genom att lägga till en glob som matchar namnen på integrationsgrenar till denna flervärdeskonfigurationsvariabel, kommer standardmeddelandet för sammanslagningar som beräknas för sammanslagningar i dessa integrationsgrenar att utelämna "into <gren-namn>" från titeln.

Antalet filer som ska beaktas i den uttömmande delen av namnbytesdetektering under en sammanslagning. Om inget anges används standardvärdet diff.renameLimit. Om varken merge.renameLimit eller diff.renameLimit anges används standardvärdet för närvarande 7000. Denna inställning har ingen effekt om namnbytesdetektering är avstängd.

Huruvida Git detekterar namnbyten. Om det är satt till false är namnbytesdetektering inaktiverad. Om det är satt till true är grundläggande namnbytesdetektering aktiverad. Standardvärdet är diff.renames.

Huruvida Git detekterar katalogbyten, vilket påverkar vad som händer vid sammanslagningstillfället med nya filer som läggs till i en katalog på ena sidan av historiken när den katalogen döptes om på den andra sidan av historiken. Möjliga värden är:

Informera Git om att den kanoniska representationen av filer i kodförråd har förändrats över tid (t.ex. tidigare incheckningar registrerade textfiler med CRLF radslut, men nyare använder LF radslut). I ett sådant kodförråd kan Git, för varje fil där en trevägs innehållssammanslagning behövs, konvertera data som registrerats i incheckningar till en kanonisk form innan en sammanslagning utförs för att minska onödiga konflikter. För mer information, se avsnittet "Sammanfoga grenar med olika inchecknings-/utcheckningsattribut" i gitattributes[5].

Vad, om något, ska skrivas ut mellan ORIG_HEAD och sammanslagningsresultatet i slutet av sammanslagningen. Möjliga värden är:

När den är satt till true skapas automatiskt en tillfällig gömma-post innan operationen börjar och tillämpas efter att operationen är avslutad. Detta innebär att du kan köra merge på ett smutsigt arbetsträd. Använd dock med försiktighet: den slutliga stash-applikationen efter en lyckad merge kan resultera i icke-triviala konflikter. Detta alternativ kan åsidosättas av alternativen --no-autostash och --autostash i git-merge[1]. Standardvärdet är false.

Kontrollerar vilket sammanslagningsverktyg som används av git-mergetool[1]. Listan nedan visar de giltiga inbyggda värdena. Alla andra värden behandlas som ett anpassat sammanslagningsverktyg och kräver att en motsvarande mergetool.<verktyg>.cmd-variabel definieras.

Styr vilket sammanslagningsverktyg som används av git-mergetool[1] när flaggan -g/--gui är specificerad. Listan nedan visar de giltiga inbyggda värdena. Alla andra värden behandlas som ett anpassat sammanslagningsverktyg och kräver att en motsvarande variabel mergetool.<gui-verktyg>.cmd definieras.

Styr mängden utdata som visas av den rekursiva sammanslagningsstrategin. Nivå 0 matar ut ingenting förutom ett slutligt felmeddelande om konflikter upptäcktes. Nivå 1 matar endast ut konflikter, 2 matar ut konflikter och filändringar. Nivå 5 och högre matar ut felsökningsinformation. Standardinställningen är nivå 2. Kan åsidosättas av miljövariabeln GIT_MERGE_VERBOSITY.

Definierar ett människoläsbart namn för en anpassad lågnivå-sammanslagningsdrivrutin. Se gitattributes[5] för mer information.

Definierar kommandot som implementerar en anpassad lågnivå-sammanslagningsdrivrutin. Se gitattributes[5] för mer information.

Namnger en lågnivå-sammanslagningsdrivrutin som ska användas vid intern sammanslagning mellan gemensamma förfäder. Se gitattributes[5] för mer information.

Åsidosätt sökvägen för det givna verktyget. Detta är användbart om ditt verktyg inte finns i $PATH.

Specify the command to invoke the specified merge tool. The specified command is evaluated in shell with the following variables available: BASE is the name of a temporary file containing the common base of the files to be merged, if available; LOCAL is the name of a temporary file containing the contents of the file on the current branch; REMOTE is the name of a temporary file containing the contents of the file from the branch being merged; MERGED contains the name of the file to which the merge tool should write the results of a successful merge.

Tillåter användaren att åsidosätta det globala värdet mergetool.hideResolved för ett specifikt verktyg. Se mergetool.hideResolved för en fullständig beskrivning.

För ett anpassat sammanslagnings-kommando anger du om avslutningskoden för sammanfognings-kommandot kan användas för att avgöra om sammanslagningen lyckades. Om detta inte är inställt på sant kontrolleras tidsstämpeln för sammanslagningsmålfilen och sammanslagningen antas ha lyckats om filen har uppdaterats. Annars uppmanas användaren att ange att sammanslagningen lyckades.

Äldre versioner av meld stöder inte alternativet --output. Git kommer att försöka upptäcka om meld stöder --output genom att inspektera utdata från meld --help. Om du konfigurerar mergetool.meld.hasOutput hoppar Git över dessa kontroller och använder det konfigurerade värdet istället. Om mergetool.meld.hasOutput ställs in på true får Git att ovillkorligen använda alternativet --output, och false undviker att använda --output.

När --auto-merge är angivet, kommer meld att sammanfoga alla icke-konfliktande delar automatiskt, markera de motstridiga delarna och vänta på användarens beslut. Om mergetool.meld.useAutoMerge sätts till true anger du att Git villkorslöst ska använda alternativet --auto-merge med meld. Om detta värde sätts till auto detekterar git om --auto-merge stöds och kommer endast att använda --auto-merge när det är tillgängligt. Värdet false undviker att använda --auto-merge helt och hållet, och är standardvärdet.

Konfigurera layouten för delade fönster för vimdiffs <variant>, vilket är någon av vimdiff, nvimdiff, gvimdiff. Vid start av git mergetool med --tool=<variant> (eller utan --tool om merge.tool är konfigurerad som <variant>), kommer Git att konsultera mergetool.<variant>.layout för att bestämma verktygets layout. Om den variantspecifika konfigurationen inte är tillgänglig används vimdiff som reserv. Om inte heller den är tillgänglig används en standardlayout med 4 fönster. För att konfigurera layouten, se BAKÄNDA-SPECIFIKA TIPS avsnitt i git-mergetool[1].

Under en sammanslagning kommer Git automatiskt att lösa så många konflikter som möjligt och skriva $MERGED-filen som innehåller konfliktmarkörer runt eventuella konflikter som den inte kan lösa; $LOCAL och $REMOTE är normalt versionerna av filen från före Gits konfliktlösning. Denna flagga gör att $LOCAL och $REMOTE skrivs över så att endast de olösta konflikterna presenteras för sammanslagningsverktyget. Kan konfigureras per verktyg via konfigurationsvariabeln mergetool.<verktyg>.hideResolved. Standardvärdet är false.

Efter att en sammanslagning har utförts kan originalfilen med konfliktmarkörer sparas som en fil med filändelsen .orig. Om variabeln är satt till false bevaras inte filen. Standardvärdet är sant (dvs. behåll säkerhetskopiorna).

När ett anpassat sammanslagningsverktyg anropas använder Git en uppsättning temporära filer för att skicka till verktyget. Om verktyget returnerar ett fel och denna variabel är satt till true, kommer dessa temporära filer att bevaras; annars kommer de att tas bort efter att verktyget har avslutats. Standardvärdet är false.

Git skriver som standard temporära BASE-, LOCAL- och REMOTE-versioner av motstridiga filer i arbetsträdet. Git kommer att försöka använda en temporär katalog för dessa filer när true är satt. Standardvärdet är false.

Prompt before each invocation of the merge resolution program.

Sätt true för att använda merge.guitool som standard (motsvarande att ange argumentet --gui), eller auto för att välja merge.guitool eller merge.tool beroende på förekomsten av ett DISPLAY miljövariabelvärde. Standardvärdet är false, där argumentet --gui måste anges explicit för att merge.guitool ska kunna användas.

Vilken sammanslagningsstrategi som ska väljas som standard vid lösande av anteckningskonflikter. Måste vara en av manual, ours, theirs, union eller cat_sort_uniq. Standardinställningen är manual. Se avsnittet "ANTECKNINGAR SAMMANSLAGNINGSSTRATEGIER" i git-notes[1] för mer information om varje strategi.

Vilken sammanslagningsstrategi man ska välja när man sammanfogar anteckningar med refs/notes/<namn>. Detta åsidosätter den mer generella notes.mergeStrategy. Se avsnittet "ANTECKNINGAR SAMMANSLAGNINGSSTRATEGIER" i git-notes[1] för mer information om tillgängliga strategier.

Vilken referens (eller referenser, om en glob eller angetts mer än en gång), utöver standardvärdet som anges av core.notesRef eller GIT_NOTES_REF, som anteckningar ska läsas från när inchecknings-meddelanden visas med kommandofamiljen git log.

När man skriver om incheckningar med <kommando> (för närvarande amend eller rebase), och variabeln är false, kommer git inte att kopiera anteckningar från originalet till den omskrivna incheckningen. Standardvärdet är true. Se även notes.rewriteRef nedan.

När anteckningar kopieras under en omskrivning (se alternativet notes.rewrite.<kommando>), avgör detta vad som ska göras om mål-incheckningen redan har en anteckning. Måste vara en av overwrite, concatenate, cat_sort_uniq eller ignore. Standardvärdet är concatenate.

När anteckningar kopieras under en omskrivning, anger detta den (fullständigt kvalificerade) referens vars anteckningar ska kopieras. Kan vara en glob, i vilket fall anteckningar i alla matchande referenser kommer att kopieras. Du kan också ange denna konfiguration flera gånger.

Om satt till true antas --set-upstream vara standard push när ingen uppströmsspårning finns för den aktuella grenen; detta alternativ träder i kraft med push.default-alternativen simple, upstream och current. Det är användbart om du som standard vill att nya grenar ska pushas till standardfjärren (som beteendet hos push.default=current) och du också vill att uppströmsspårningen ska vara inställd. Arbetsflöden som sannolikt kommer att dra nytta av detta alternativ är enkla centrala arbetsflöden där alla grenar förväntas ha samma namn på fjärren.

Definierar åtgärden git push ska utföra om ingen refspec anges (vare sig från kommandoraden, konfigurationen eller någon annanstans). Olika värden är väl lämpade för specifika arbetsflöden; till exempel, i ett rent centralt arbetsflöde (dvs. hämtningskällan är lika med push-destinationen) är upstream förmodligen vad du vill ha. Möjliga värden är:

Om den är satt till sant, aktivera alternativet --follow-tags som standard. Du kan åsidosätta denna konfiguration vid skicka-tillfället (push) genom att ange --no-follow-tags.

Kan sättas till ett booleskt värde, eller strängen if-asked. Ett sant värde gör att alla sändningar (push) GPG-signeras, som om --signed skickas till git-push[1]. Strängen if-asked gör att push-filer signeras om servern stöder det, som om --signed=if-asked skickas till git push. Ett falskt värde kan åsidosätta ett värde från en konfigurationsfil med lägre prioritet. En explicit kommandoradsflagga åsidosätter alltid detta konfigurationsalternativ.

När inget --push-option=<alternativ>-argument anges från kommandoraden, beter sig git push som om varje <alternativ> i denna variabel anges som --push-option=<alternativ>.

Exempel:

/etc/gitconfig
  push.pushoption = a
  push.pushoption = b

~/.gitconfig
  push.pushoption = c

repo/.git/config
  push.pushoption =
  push.pushoption = b

Detta kommer att resultera i att endast b (a och c är nollställda).

Kan vara check, on-demand, only eller no, med samma beteende som push --recurse-submodules. Om inte angivet används no som standard, såvida inte submodule.recurse är angivet (i vilket fall ett true-värde betyder on-demand).

Om den är satt till true motsvarar det att ange --force-if-includes som ett alternativ till git-push[1] i kommandoraden. Att lägga till --no-force-if-includes vid tidpunkten för push åsidosätter denna konfigurations-inställning.

Om värdet är satt till true, försök att minska storleken på packfilen som skickas genom förhandlingsrundor där klienten och servern försöker hitta gemensamma incheckningar. Om false kommer Git att förlita sig enbart på serverns referensannonsering för att hitta gemensamma incheckningar.

Om satt till false, inaktiveras användningen av bitmappar för git push även om pack.useBitmaps är true, utan att förhindra att andra git-operationer använder bitmappar. Standardvärdet är true.

Standard-bakända att använda för ombasering. Möjliga val är apply (tillämpa) eller merge (sammanslå). Om sammanfognings-bakändan i framtiden får alla återstående funktioner från tillämpa-bakändan , kan den här inställningen bli oanvänd.

Whether to show a diffstat of what changed upstream since the last rebase. False by default.

Om satt till sant, aktivera alternativet --autosquash i git-rebase[1] som standard för interaktivt läge. Detta kan åsidosättas med alternativet --no-autosquash.

När den är satt till sant, skapas automatiskt en tillfällig gömma-post innan operationen börjar, och tillämpas efter att operationen är avslutad. Detta innebär att du kan köra rebase på ett smutsigt arbetsträd. Använd dock försiktigt: den slutliga gömma-applikationen efter en lyckad ombasering kan resultera i icke-triviala konflikter. Detta alternativ kan åsidosättas av alternativen --no-autostash och --autostash i git-rebase[1]. Standardvärdet är falskt.

Om satt till sant aktiveras alternativet --update-refs som standard.

Om satt till "warn" (varna), kommer git rebase -i att skriva ut en varning om vissa incheckningar tas bort (t.ex. om en rad raderades), men ombaseringen kommer fortfarande att fortsätta. Om satt till "error" kommer den att skriva ut den föregående varningen och stoppa ombaseringen. git rebase --edit-todo kan sedan användas för att korrigera felet. Om satt till "ignore" görs ingen kontroll. För att ta bort en incheckning utan varning eller fel, använd kommandot drop i att-göra-listan. Standardinställningen är "ignore".

En formatsträng, som specificerad i git-log[1], som ska användas för att-göra-listan under en interaktiv ombasering. Formatet kommer automatiskt att ha inchecknings-hashen till formatet.

Om satt till sant, kommer git rebase att använda förkortade kommandonamn i att-göra-listan vilket resulterar i något liknande:

	p deadbee The oneline of the commit
	p fa1afe1 The oneline of the next commit
	...

	pick deadbee The oneline of the commit
	pick fa1afe1 The oneline of the next commit
	...

Schemalägg automatiskt exec-kommandon som misslyckades. Detta är bara logiskt i interaktivt läge (eller när ett --exec-alternativ angavs). Detta är samma sak som att ange --reschedule-failed-exec-alternativet.

Om den är satt till falskt, sätt alternativet --no-fork-point som standard.

Om och hur alternativet --rebase-merges ska ställas in som standard. Kan vara rebase-cousins, no-rebase-cousins eller ett booleskt värde. Att sätta till true eller no-rebase-cousins motsvarar --rebase-merges=no-rebase-cousins, att sätta till rebase-cousins motsvarar --rebase-merges=rebase-cousins, och att sätta till false(falsk) motsvarar --no-rebase-merges. Att skicka --rebase-merges på kommandoraden, med eller utan ett argument, åsidosätter alla rebase.rebaseMerges-konfigurationer.

Vid generering av etikettnamn från inlämningsrubriker, korta av namnen till denna längd. Som standard kortas namnen av till något mindre än NAME_MAX (för att tillåta att exempelvis .lock-filer kan skrivas för motsvarande lösa referenser).

Textredigerare som används av git rebase -i för att redigera instruktionsfilen för ombasering. Värdet är avsett att tolkas av skalet när det används. Det kan åsidosättas av miljövariabeln GIT_SEQUENCE_EDITOR. När den inte är konfigurerad, används standardredigeraren för inchecknings-meddelanden istället.

Om detta är satt till sant, kommer git stash apply och git stash pop att bete sig som om --index angavs. Standardvärdet är falskt. See the descriptions in git-stash[1].

Om detta är satt till sant, kommer kommandot git stash show att visa de ospårade filerna från en gömma-post. Standardvärdet är falskt. See the description of the 'show' command in git-stash[1].

Om detta är satt till sant, kommer kommandot git stash show utan ett alternativ att visa gömma-posten i patch-format. Standardvärdet är falskt. See the description of the 'show' command in git-stash[1].

Om detta är satt till sant, kommer kommandot git stash show utan ett alternativ att visa en diffstat för gömma-posten. Standardinställningen är sant. See the description of the 'show' command in git-stash[1].

Ett booleskt värde som anger om skapade annoterade taggar ska vara GPG-signerade. Om --annotate anges på kommandoraden har det företräde framför detta alternativ.

Denna variabel styr sorteringsordningen för taggar när de visas av git-tag[1]. Utan alternativet --sort=<value> anges, kommer värdet på denna variabel att användas som standard.

En booleskt värde som anger om alla taggar ska GPG-signeras. Användning av det här alternativet när du kör i ett automatiserat skript kan resultera i att ett stort antal taggar signeras. Det är därför bekvämt att använda en agent för att undvika att skriva in din GPG-lösenfras flera gånger. Observera att det här alternativet inte påverkar taggsigneringsbeteendet som aktiveras av alternativen -u <keyid> eller --local-user=<keyid>.

Om ingen gren anges och varken -b, -B eller --detach används, skapar git worktree add som standard en ny gren från HEAD. Om worktree.guessRemote är satt till sant, försöker worktree add hitta en fjärrspårningsgren vars namn unikt matchar det nya grennamnet. Om en sådan gren finns, checkas den ut och sätts som "uppströms" för den nya grenen. Om ingen sådan matchning kan hittas, återgår den till att skapa en ny gren från den aktuella HEAD.

Länka arbetsträd med relativa sökvägar (när "true") eller absoluta sökvägar (när "false"). Detta är särskilt användbart för inställningar där förvaret och arbetsträden kan flyttas mellan olika platser eller miljöer. Standardvärdet är "false".