Skip to content

Commit 9c6edb1

Browse files
author
dscho
committed
Update translated manual pages
Updated via the `update-translated-manual-pages.yml` GitHub workflow.
1 parent bd3b0b7 commit 9c6edb1

256 files changed

Lines changed: 60775 additions & 315 deletions

File tree

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.
Lines changed: 86 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,86 @@
1+
git-merge-file(1)
2+
=================
3+
4+
NAMN
5+
----
6+
git-merge-file - Kör en trevägs filsammanslagning
7+
8+
9+
SYNOPSIS
10+
--------
11+
[verse]
12+
'git merge-file' [-L <nuvarande-namn> [-L <bas-namn> [-L <annat-namn>]]]
13+
[--ours|--theirs|--union] [-p|--stdout] [-q|--quiet] [--marker-size=<n>]
14+
[--[no-]diff3] [--object-id] <nuvarande> <bas> <annat>
15+
16+
17+
BESKRIVNING
18+
-----------
19+
Givet tre filer `<nuvarande>`, `<bas>` och `<annat>`, införlivar 'git merge-file' alla ändringar som leder från `<bas>` till `<annat>` i `<nuvarande>`. Resultatet hamnar vanligtvis i `<nuvarande>`. 'git merge-file' är användbart för att kombinera separata ändringar i ett original. Anta att `<bas>` är originalet, och både `<nuvarande>` och `<annat>` är modifieringar av `<bas>`, då kombinerar 'git merge-file' båda ändringarna.
20+
21+
En konflikt uppstår om både `<nuvarande>` och `<annat>` har ändringar i ett gemensamt radsegment. Om en konflikt hittas, utfärdar `git merge-file` normalt en varning och ställer konflikten i parentes med rader som innehåller markörerna <<<<<<< och >>>>>>>>. En typisk konflikt ser ut så här:
22+
23+
<<<<<<< A
24+
rader i filen A
25+
=======
26+
rader i filen B
27+
>>>>>>> B
28+
29+
Om det finns konflikter, bör användaren redigera resultatet och ta bort ett av alternativen. När alternativet `--ours`, `--theirs` eller `--union` är aktivt löses dessa konflikter och gynnar rader från `<nuvarande>`, rader från `<annat>` eller rader från båda. Längden på konfliktmarkörerna kan anges med alternativet `--marker-size`.
30+
31+
Om `--object-id` anges inträffar exakt samma beteende, förutom att istället för att ange vad som ska sammanfogas som filer, anges det som en lista med objekt-ID:n som refererar till blobbar.
32+
33+
Programmets utgångsvärde är negativt vid fel, och antalet konflikter i övrigt (avkortat till 127 om det finns fler än så många konflikter). Om sammanslagningen var ren är utgångsvärdet 0.
34+
35+
'git merge-file' är utformad för att vara en minimal klon av RCS 'merge'; det vill säga, den implementerar all RCS 'merge' funktionalitet som behövs av linkgit:git[1].
36+
37+
38+
ALTERNATIV
39+
----------
40+
41+
--object-id::
42+
Ange innehållet som ska sammanfogas som blobbar i den aktuella förvaret istället för filer. I det här fallet måste åtgärden ske i en giltigt förvar.
43+
+
44+
Om alternativet `-p` anges går den sammanfogade filen (inklusive eventuella konflikter) till standardutdata som vanligt; annars skrivs den sammanfogade filen till objektarkivet och objekt-ID:t för dess blob skrivs till standardutdata.
45+
46+
-L <etikett>::
47+
Det här alternativet kan anges upp till tre gånger och anger etiketter som ska användas istället för motsvarande filnamn i konfliktrapporter. Det vill säga, `git merge-file -L x -L y -L z a b c` genererar utdata som ser ut som att den kommer från filerna x, y och z istället för från filerna a, b och c.
48+
49+
-p::
50+
Skicka resultat till standardutdata istället för att skriva över `<nuvarande>`.
51+
52+
-q::
53+
Tyst; varna inte för konflikter.
54+
55+
--diff3::
56+
Visa konflikter i "diff3"-stil.
57+
58+
--zdiff3::
59+
Visa konflikter i "zdiff3"-stil.
60+
61+
--ours::
62+
--theirs::
63+
--union::
64+
Istället för att lämna konflikter kvar i filen, lös konflikter som gynnar vår (eller deras eller båda) sida av linjerna.
65+
66+
--diff-algorithm={patience|minimal|histogram|myers}::
67+
Använd en annan diff-algoritm vid sammanfogning. Den nuvarande standarden är "myers", men att välja en nyare algoritm som "histogram" kan hjälpa till att undvika felsammanfogningar som uppstår på grund av oviktiga matchande linjer (som klammerparenteser från olika funktioner). Se även linkgit:git-diff[1] `--diff-algorithm`.
68+
69+
EXEMPEL
70+
-------
71+
72+
`git merge-file README.my README README.upstream`::
73+
74+
kombinerar ändringarna i README.my och README.upstream sedan README, försöker sammanfoga dem och skriver resultatet till README.my.
75+
76+
`git merge-file -L a -L b -L c tmp/a123 tmp/b234 tmp/c345`::
77+
78+
slår samman tmp/a123 och tmp/c345 med basen tmp/b234, men använder etiketterna `a` och `c` istället för `tmp/a123` och `tmp/c345`.
79+
80+
`git merge-file -p --object-id abc1234 def567 890abcd`::
81+
82+
kombinerar ändringarna i blobben abc1234 och 890abcd sedan def567, försöker slå samman dem och skriver resultatet till standardutdata
83+
84+
GIT
85+
---
86+
En del av linkgit:git[1]-sviten
Lines changed: 133 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,133 @@
1+
git-checkout-index(1)
2+
=====================
3+
4+
NAMN
5+
----
6+
git-checkout-index - Kopiera filer från indexet till arbetskatalog
7+
8+
9+
SYNOPSIS
10+
--------
11+
[verse]
12+
'git checkout-index' [-u] [-q] [-a] [-f] [-n] [--prefix=<sträng>]
13+
[--stage=<number>|all]
14+
[--temp]
15+
[--ignore-skip-worktree-bits]
16+
[-z] [--stdin]
17+
[--] [<fil>...]
18+
19+
BESKRIVNING
20+
-----------
21+
Kopierar alla listade filer från indexet till arbetskatalogen (skriver inte över befintliga filer).
22+
23+
ALTERNATIV
24+
----------
25+
-u::
26+
--index::
27+
uppdatera statistikinformation för de utcheckade posterna i indexfilen.
28+
29+
-q::
30+
--quiet::
31+
var tyst om filer finns eller inte finns i indexet
32+
33+
-f::
34+
--force::
35+
tvinga överskrivning av befintliga filer
36+
37+
-a::
38+
--all::
39+
kontrollerar alla filer i indexet förutom de med skip-worktree-biten satt (se `--ignore-skip-worktree-bits`). Kan inte användas tillsammans med explicita filnamn.
40+
41+
-n::
42+
--no-create::
43+
Checka inte ut nya filer, uppdatera bara filer som redan är utcheckade.
44+
45+
--prefix=<sträng>::
46+
När du skapar filer, lägg till <sträng> före (vanligtvis en katalog med en avslutande /)
47+
48+
--stage=<nummer>|all::
49+
Istället för att checka ut osammanslagna poster, kopiera ut filerna från det namngivna steget. <nummer> måste vara mellan 1 och 3. Obs: --stage=all innebär automatiskt --temp.
50+
51+
--temp::
52+
Istället för att kopiera filerna till arbetskatalogen, skriv innehållet till temporära filer. De temporära namnassociationerna kommer att skrivas till stdout.
53+
54+
--ignore-skip-worktree-bits::
55+
Kolla ut alla filer, inklusive de med skip-worktree-biten uppsatt.
56+
57+
--stdin::
58+
Istället för att hämta en lista med sökvägar från kommandoraden, läs listan med sökvägar från standardinmatningen. Sökvägar separeras som standard med LF (dvs. en sökväg per rad).
59+
60+
-z::
61+
Endast meningsfullt med `--stdin`; sökvägar separeras med NUL-tecknet istället för LF.
62+
63+
\--::
64+
Tolka inte fler argument som alternativ.
65+
66+
Flaggornas ordning brukade spela roll, men inte längre.
67+
68+
Att bara göra `git checkout-index` gör ingenting. Du menade förmodligen `git checkout-index -a`. Och om du vill tvinga fram det, vill du ha `git checkout-index -f -a`.
69+
70+
Intuitivitet är inte målet här. Repeterbarhet är. Anledningen till beteendet "inga argument betyder inget arbete" är att man från skript ska kunna göra:
71+
72+
----------------
73+
$ find . -name '*.h' -print0 | xargs -0 git checkout-index -f --
74+
----------------
75+
76+
vilket tvingar alla befintliga `*.h`-filer att ersättas med deras cachade kopior. Om en tom kommandorad antydde "all", skulle detta tvinga fram en uppdatering av allt i indexet, vilket inte var poängen. Men eftersom 'git checkout-index' accepterar --stdin skulle det vara snabbare att använda:
77+
78+
----------------
79+
$ find . -name '*.h' -print0 | git checkout-index -f -z --stdin
80+
----------------
81+
82+
`--` är en bra idé när du vet att resten kommer att vara filnamn; det kommer att förhindra problem med ett filnamn på till exempel `-a`. Att använda `--` är förmodligen en bra policy i skript.
83+
84+
85+
Använda --temp eller --stage=all
86+
--------------------------------
87+
När `--temp` används (eller antyds av `--stage=all`) skapar 'git checkout-index' en temporär fil för varje indexpost som checkas ut. Indexet uppdateras inte med statistikinformation. Dessa alternativ kan vara användbara om anroparen behöver alla steg i alla icke-sammanslagna poster så att de icke-sammanslagna filerna kan bearbetas av ett externt sammanslagningsverktyg.
88+
89+
En lista kommer att skrivas till stdout och tillhandahålla associationen av temporära filnamn till spårade sökvägar. Listformatet har två varianter:
90+
91+
. tillfälligt namn TAB-sökväg RS
92+
+
93+
Det första formatet används när `--stage` utelämnas eller inte är `--stage=all`. Fältet tempname är det temporära filnamnet som innehåller filinnehållet och path är det spårade sökvägsnamnet i indexet. Endast de begärda posterna matas ut.
94+
95+
. steg1temp SP steg2temp SP steg3temp TAB-sökväg RS
96+
+
97+
Det andra formatet används när `--stage=all`. De tre fälten för temporära steg (steg1temp, steg2temp, steg3temp) listar namnet på den temporära filen om det finns en stegpost i indexet eller `.` om det inte finns någon stegpost. Sökvägar som bara har en steg 0-post kommer alltid att utelämnas från utdata.
98+
99+
I båda formaten är RS (postavgränsaren) som standard nyrad men kommer att vara nullbyte om -z skickades på kommandoraden. De temporära filnamnen är alltid säkra strängar; de kommer aldrig att innehålla katalogavgränsare eller blanksteg. Sökvägsfältet är alltid relativt till den aktuella katalogen och de temporära filnamnen är alltid relativa till den översta katalogen.
100+
101+
Om objektet som kopieras till en temporär fil är en symbolisk länk kommer länkens innehåll att skrivas till en vanlig fil. Det är upp till slutanvändaren eller Porcelain att använda denna information.
102+
103+
104+
EXEMPEL
105+
-------
106+
För att uppdatera och uppdatera endast de filer som redan är utcheckade::
107+
+
108+
----------------
109+
$ git checkout-index -n -f -a && git update-index --ignore-missing --refresh
110+
----------------
111+
112+
Använda 'git checkout-index' för att "exportera ett helt träd"::
113+
Prefixfunktionen gör det i princip enkelt att använda 'git checkout-index' som en "export as tree"-funktion. Läs bara in önskat träd i indexet och gör:
114+
+
115+
----------------
116+
$ git checkout-index --prefix=git-export-dir/ -a
117+
----------------
118+
+
119+
`git checkout-index` kommer att "exportera" indexet till den angivna katalogen.
120+
+
121+
Den sista "/"-strängen är viktig. Det exporterade namnet har bokstavligen bara den angivna strängen som prefix. Jämför detta med följande exempel.
122+
123+
Exportera filer med ett prefix::
124+
+
125+
----------------
126+
$ git checkout-index --prefix=.merged- Makefile
127+
----------------
128+
+
129+
Detta kommer att checka ut den för närvarande cachade kopian av `Makefile` i filen `.merged-Makefile`.
130+
131+
GIT
132+
---
133+
En del av linkgit:git[1]-sviten
Lines changed: 66 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,66 @@
1+
git-sh-setup(1)
2+
===============
3+
4+
NAMN
5+
----
6+
git-sh-setup - Vanlig installationskod för Git-shellskript
7+
8+
SYNOPSIS
9+
--------
10+
[verse]
11+
'. "$(git --exec-path)/git-sh-setup"'
12+
13+
BESKRIVNING
14+
-----------
15+
16+
Detta är inte ett kommando som slutanvändaren någonsin skulle vilja köra. Den här dokumentationen är avsedd för personer som studerar Porslinsliknande skript och/eller skriver nya.
17+
18+
Skriptleten 'git sh-setup' är utformad för att hämtas (med `.`) från andra shell-skript för att ställa in vissa variabler som pekar mot de vanliga Git-katalogerna och några få hjälpfunktioner i shell-skriptet.
19+
20+
Innan du skapar sourcade-funktioner bör ditt skript ställa in några variabler; `USAGE` (och `LONG_USAGE`, om sådan finns) används för att definiera meddelandet som ges av skalfunktionen `usage()`. `SUBDIRECTORY_OK` kan ställas in om skriptet kan köras från en underkatalog i arbetskatalogen (vissa kommandon gör det inte).
21+
22+
Skriptleten anger skalvariablerna `GIT_DIR` och `GIT_OBJECT_DIRECTORY`, men exporterar dem *inte* till miljön.
23+
24+
FUNKTIONER
25+
----------
26+
27+
die::
28+
avsluta efter att ha skickat det angivna felmeddelandet till standardfelströmmen.
29+
30+
usage::
31+
dö med användningsmeddelandet.
32+
33+
set_reflog_action::
34+
Sätt `GIT_REFLOG_ACTION`-miljön till en given sträng (vanligtvis programmets namn) om den inte redan är angiven. Närhelst skriptet kör ett `git`-kommando som uppdaterar referenser skapas en reflog-post med värdet på denna sträng för att lämna posten över vilket kommando som uppdaterade referensen.
35+
36+
git_editor::
37+
kör en editor som användaren väljer (GIT_EDITOR, core.editor, VISUAL eller EDITOR) på en given fil, men ger ett felmeddelande om ingen editor anges och terminalen är dum.
38+
39+
is_bare_repository::
40+
matar ut `sant` eller `false` till standardutdataströmmen för att indikera om förvaret är ett bart förråd (dvs. utan ett associerad arbetskatalog).
41+
42+
cd_to_toplevel::
43+
Kör chdir till den översta nivån i arbetskatalogen.
44+
45+
require_work_tree::
46+
kontrollerar om den aktuella katalogen finns inom förvarets arbetskatalog, och dör annars.
47+
48+
require_work_tree_exists::
49+
kontrollerar om arbetskatalog som är associerat med förvaret existerar, och dör annars. Görs ofta innan cd_to_toplevel anropas, vilket är omöjligt att göra om det inte finns någon arbetskatalog.
50+
51+
require_clean_work_tree <handling> [<ledtråd>]::
52+
kontrollerar att arbetskatalog och indexet som är associerat med arkivet inte har några obekräftade ändringar i spårade filer. Annars visas ett felmeddelande av typen `Kan inte <åtgärd>: <orsak>. <ledtråd>` och programmet dör. Exempel:
53+
+
54+
----------------
55+
require_clean_work_tree rebase "Please commit or stash them."
56+
----------------
57+
58+
get_author_ident_from_commit::
59+
matar ut kod för användning med eval för att ställa in variablerna GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL och GIT_AUTHOR_DATE för en given incheckning.
60+
61+
create_virtual_base::
62+
ändrar den första filen så att endast rader som är gemensamma med den andra filen återstår. Om det inte finns tillräckligt med gemensamt material lämnas den första filen tom. Resultatet är lämpligt som en virtuell basindata för en 3-vägs sammanslagning.
63+
64+
GIT
65+
---
66+
En del av linkgit:git[1]-sviten

0 commit comments

Comments
 (0)