git-rev-parse - Online in de cloud

PROGRAMMA:

NAAM

git-rev-parse - Parameters uitkiezen en masseren

KORTE INHOUD

git rev-ontleed [ --keuze ] ...

PRODUCTBESCHRIJVING

Veel Git-porseleinachtige commando's gebruiken een combinatie van vlaggen (dat wil zeggen parameters die beginnen met a
scheutje -) en parameters bedoeld voor de onderliggende waarde git rev-lijst commando dat ze intern gebruiken
en vlaggen en parameters voor de andere opdrachten die ze stroomafwaarts gebruiken git rev-lijst. Deze
commando wordt gebruikt om onderscheid te maken tussen hen.

OPTIES

Werking Modes
Elk van deze opties moet als eerste op de opdrachtregel verschijnen.

--parseopt
Te gebruiken git rev-ontleed in optie-parseermodus (zie het gedeelte PARSEOPT hieronder).

--sq-citaat
Te gebruiken git rev-ontleed in de shell-quote-modus (zie SQ-QUOTE-sectie hieronder). In contrast met
de --sq optie hieronder, deze modus doet alleen aanhalingstekens. Er wordt niets anders gedaan om te bevelen
invoer.

Opties For --parseopt
--blijf-dashdash
Alleen zinvol in de --parseopt-modus. Vertelt de optieparser om de eerste echo uit te voeren --
ontmoet in plaats van het over te slaan.

--stop-bij-niet-optie
Alleen zinvol in de --parseopt-modus. Laat de optieparser bij de eerste stoppen
non-optie argument. Dit kan worden gebruikt om subopdrachten te ontleden die opties bevatten
zich.

--lang vast
Alleen zinvol in de --parseopt-modus. Voer de opties uit in hun lange vorm if
beschikbaar, en met hun argumenten vast.

Opties For Filtering
--alleen toerental
Voer geen vlaggen en parameters uit die niet bedoeld zijn git rev-lijst opdracht.

--geen toerental
Voer geen vlaggen en parameters uit die bedoeld zijn voor git rev-lijst opdracht.

--vlaggen
Voer geen niet-vlagparameters uit.

--geen-vlaggen
Voer geen vlagparameters uit.

Opties For uitgang
--standaard
Als er geen parameter door de gebruiker is opgegeven, gebruik dan in plaats van.

--voorvoegsel
Gedraag je alsof git rev-ontleed werd aangeroepen vanuit de submap van de werkende
boom. Alle relatieve bestandsnamen worden omgezet alsof ze voorafgegaan worden door en zal zijn
in die vorm afgedrukt.

Dit kan worden gebruikt om argumenten om te zetten in een opdracht die in een submap wordt uitgevoerd, zodat ze
kan nog steeds worden gebruikt nadat u naar het hoogste niveau van de repository bent gegaan. Bijvoorbeeld:

prefix=$(git rev-parse --show-prefix)
cd "$(git rev-parse --show-toplevel)"
eval "set -- $(git rev-parse --sq --prefix "$prefix" "$@")"

--verifiëren
Controleer of er precies één parameter is opgegeven en dat deze kan worden omgezet in een onbewerkte parameter
20-byte SHA-1 die kan worden gebruikt om toegang te krijgen tot de objectdatabase. Als dat zo is, stuur het dan naar de
standaarduitvoer; anders fout.

Als u er zeker van wilt zijn dat de uitvoer daadwerkelijk een object in uw object een naam geeft
database en/of kan worden gebruikt als een specifiek type object dat u nodig heeft, kunt u de
^{type} peeling-operator voor de parameter. Git rev-parse bijvoorbeeld "$VAR^{commit}"
zal ervoor zorgen dat $VAR een bestaand object een naam geeft die een commit-ish is (dat wil zeggen een commit, of
een geannoteerde tag die naar een commit verwijst). Om er zeker van te zijn dat $VAR een bestaand
object van elk type, git rev-parse "$VAR^{object}" kan worden gebruikt.

-q, --stil
Alleen zinvol in de modus --verify. Geef geen foutmelding als het eerste argument
is geen geldige objectnaam; in plaats daarvan stilletjes afsluiten met een niet-nulstatus. SHA-1's voor
geldige objectnamen worden bij succes afgedrukt.

--vierkant
Gewoonlijk bestaat de uitvoer uit één regel per vlag en parameter. Deze optie maakt uitvoer a
enkele regel, correct genoteerd voor verbruik door shell. Handig wanneer u uw
parameter om spaties en nieuwe regels te bevatten (bijvoorbeeld bij gebruik van pikhouweel -S with git
verschil-*). In tegenstelling tot de --sq-quote optie wordt de commando-invoer nog steeds geïnterpreteerd
zoals gewoonlijk.

--niet
Wanneer u objectnamen weergeeft, plaatst u deze vooraf met ^ en strippen ^ voorvoegsel uit de objectnamen
die er al een hebben.

--abbrev-ref[=(strikt|los)]
Een niet-dubbelzinnige korte naam van de objectnaam. De optie core.warnAmbiguousRefs is
gebruikt om de strikte afkortingsmodus te selecteren.

--kort, --kort=getal
In plaats van de volledige SHA-1-waarden van objectnamen uit te voeren, probeer ze af te korten
een kortere unieke naam. Als er geen lengte is opgegeven, wordt 7 gebruikt. De minimale lengte is 4.

--symbolisch
Meestal worden de objectnamen in SHA-1-vorm uitgevoerd (met mogelijk ^ voorvoegsel); dit
optie zorgt ervoor dat ze worden uitgevoerd in een vorm die zo dicht mogelijk bij de oorspronkelijke invoer ligt.

--symbolische-volledige-naam
Dit is vergelijkbaar met --symbolic, maar het laat invoer weg die geen refs zijn (dat wil zeggen vertakking of
tagnamen; of meer expliciet de "heads/master"-vorm ondubbelzinnig maken, wanneer je dat wilt
geef de branch "master" een naam als er een tag met de helaas genoemde naam "master" is, en show
ze als volledige refnames (bijvoorbeeld "refs/heads/master").

Opties For Objecten
--alle
Toon alle refs gevonden in refs/.

--branches[=patroon], --tags[=patroon], --remotes[=patroon]
Toon respectievelijk alle vestigingen, tags of op afstand gevolgde vestigingen (dwz gevonden referenties).
in respectievelijk refs/heads, refs/tags of refs/remotes).

Als er een patroon wordt gegeven, worden alleen referenties weergegeven die overeenkomen met de gegeven shell-glob. Als de
patroon bevat geen globing-teken (?, * of [), maar wordt omgezet in een voorvoegsel
overeenkomen door /* toe te voegen.

--glob=patroon
Toon alle refs die overeenkomen met het patroonpatroon van de schelp. Als het patroon niet start
met refs/ wordt dit automatisch voorafgegaan. Als het patroon geen
globing-teken (?, * of [), wordt het omgezet in een voorvoegselovereenkomst door /* toe te voegen.

--uitsluiten=
Neem geen overeenkomende referenties op dat de volgende --all, --takken, --tags,
--remotes, of --glob zou anders overwegen. Herhalingen van deze optie stapelen zich op
uitsluitingspatronen tot aan de volgende --all, --branches, --tags, --remotes, of --glob
optie (andere opties of argumenten verwijderen geaccumuleerde patronen niet).

De gegeven patronen mogen niet beginnen met refs/heads, refs/tags of refs/remotes wanneer
toegepast op respectievelijk --branches, --tags of --remotes, en ze moeten beginnen met
refs/ wanneer toegepast op --glob of --all. Indien een achterstand /* bedoeld is, moet het gegeven worden
uitdrukkelijk.

--ondubbelzinnig=
Toon elk object waarvan de naam begint met het opgegeven voorvoegsel. De moet bij zijn
minimaal 4 hexadecimale cijfers lang om te voorkomen dat elk object in de lijst wordt vermeld
per ongeluk opgeslagen.

Opties For Bestanden
--local-env-vars
Vermeld de GIT_*-omgevingsvariabelen die lokaal zijn voor de repository (bijvoorbeeld GIT_DIR of
GIT_WORK_TREE, maar niet GIT_EDITOR). Alleen de namen van de variabelen worden vermeld, niet
hun waarde, ook al zijn ze vastgelegd.

--git-dir
Toon $GIT_DIR indien gedefinieerd. Toon anders het pad naar de map .git. Het pad
getoond, indien relatief, is relatief ten opzichte van de huidige werkmap.

Als $GIT_DIR niet is gedefinieerd en niet wordt gedetecteerd dat de huidige map in een Git ligt
repository of werkboom print een bericht naar stderr en sluit af met een niet-nulstatus.

--git-common-dir
Toon $GIT_COMMON_DIR indien gedefinieerd, anders $GIT_DIR.

--is-in-git-dir
Wanneer de huidige werkmap zich onder de repositorymap bevindt, drukt u "true" af,
anders "vals".

--is-in-werk-boom
Wanneer de huidige werkmap zich in de werkboom van de repository bevindt, wordt afgedrukt
‘waar’, anders ‘onwaar’.

--is-bare-repository
Wanneer de repository kaal is, drukt u "true" af, anders "false".

--resolve-git-dir
Controleer of is een geldige repository of een gitfile die naar een geldige repository verwijst,
en druk de locatie van de repository af. Als is een gitfile en dan is het opgelost
pad naar de echte repository wordt afgedrukt.

--git-pad
Los '$GIT_DIR/ op " en neemt andere variabelen voor padverplaatsing, zoals
$GIT_OBJECT_DIRECTORY, $GIT_INDEX_FILE... op rekening. Bijvoorbeeld als
$GIT_OBJECT_DIRECTORY is ingesteld op /foo/bar en vervolgens op "git rev-parse --git-path objecten/abc"
retourneert /foo/bar/abc.

--show-cdup
Wanneer de opdracht wordt aangeroepen vanuit een submap, geeft u het pad van het hoogste niveau weer
map relatief ten opzichte van de huidige map (meestal een reeks "../", of een
lege tekenreeks).

--show-voorvoegsel
Wanneer de opdracht wordt aangeroepen vanuit een submap, geeft u het pad van de huidige map weer
map relatief ten opzichte van de map op het hoogste niveau.

--show-topniveau
Toon het absolute pad van de map op het hoogste niveau.

--gedeeld-index-pad
Toon het pad naar het gedeelde indexbestand in de gesplitste indexmodus, of leeg als dit niet het geval is
split-index-modus.

Overige Opties
--sinds=datumtekenreeks, --after=datumtekenreeks
Parseer de datumtekenreeks en voer de overeenkomstige --max-age= parameter uit voor git
rev-lijst.

--tot=datumtekenreeks, --before=datumtekenreeks
Parseer de datumtekenreeks en voer de overeenkomstige --min-age= parameter uit voor git
rev-lijst.

...
Vlaggen en parameters die moeten worden geparseerd.

SPECIFICEREN: HERZIENINGEN

Een revisieparameter typisch, maar niet noodzakelijkerwijs, wordt een commit-object benoemd. Het gebruikt
wat heet een uitgebreid SHA-1 syntaxis. Hier zijn verschillende manieren om objectnamen te spellen. De
degenen die aan het einde van deze lijst staan, noemen bomen en blobs die in een commit zijn opgenomen.

, bijv dae86e1950b1277e545cee180551750029cfe735, dae86e
De volledige SHA-1-objectnaam (hexadecimale tekenreeks van 40 bytes), of een leidende subtekenreeks
is uniek binnen de repository. Bijvoorbeeld dae86e1950b1277e545cee180551750029cfe735 en
dae86e noemen beide hetzelfde commit-object als er geen ander object in uw repository aanwezig is
waarvan de objectnaam begint met dae86e.

, bijv v1.7.4.2-679-g3bee7fb
Uitvoer van git beschrijven; dat wil zeggen een dichtstbijzijnde tag, eventueel gevolgd door een liggend streepje en een
aantal commits, gevolgd door een streepje, a gen een verkorte objectnaam.

, bijv meester, hoofden/meester, refs/hoofden/master
Een symbolische referentienaam. Bijv meester betekent doorgaans het commit-object waarnaar wordt verwezen
refs/hoofden/master. Als je beide hebt hoofden/meester en tags/master, Kunt u
expliciet zeggen hoofden/meester om Git te vertellen welke je bedoelt. Bij onduidelijkheid: a
wordt ondubbelzinnig gemaakt door de eerste wedstrijd te spelen volgens de volgende regels:

1. Als $GIT_DIR/ bestaat, dat is wat je bedoelt (dit is meestal alleen nuttig
For HEAD, FETCH_HEAD, ORIG_HEAD, MERGE_HEAD en CHERRY_PICK_HEAD);

2. anders, scheidsrechters/ als het bestaat;

3. anders, refs/tags/ als het bestaat;

4. anders, refs/hoofden/ als het bestaat;

5. anders, refs/afstandsbedieningen/ als het bestaat;

6. anders, refs/afstandsbedieningen/ /HOOFD als het bestaat.

HEAD noemt de commit waarop je de wijzigingen in de werkboom hebt gebaseerd.
FETCH_HEAD registreert de branch die u met uw
laatste git fetch-aanroep. ORIG_HEAD wordt gemaakt door opdrachten die uw HEAD
op een drastische manier de positie van de HEAD vóór hun operatie, dus
dat je de punt van de tak gemakkelijk terug kunt zetten naar de staat voordat je ging rennen
Hen. MERGE_HEAD registreert de commit(s) die u in uw branch merget
wanneer je git merge uitvoert. CHERRY_PICK_HEAD registreert de commit die u bent
cherry-picking als je git cherry-pick uitvoert.

Houd er rekening mee dat elk van de scheidsrechters/* bovenstaande gevallen kunnen afkomstig zijn van de $GIT_DIR/refs
map of uit de $GIT_DIR/packed-refs bestand. Terwijl de ref-naamcodering is
niet gespecificeerd, UTF-8 heeft de voorkeur omdat sommige uitvoerverwerking ref-namen kan aannemen in
UTF-8.

@
@ alleen is een kortere weg voor HEAD.

@{ }, bijv meester@{gisteren}, HOOFD@{5 minuten geleden}
Een ref gevolgd door het achtervoegsel @ met een datumaanduiding ingesloten in een accoladepaar
(bv {gisteren}, {1 maand 2 weken 3 dagen 1 uur 1 tweede geleden} or {1979-02-26
18:30:00}) specificeert de waarde van de ref op een eerder tijdstip. Dit achtervoegsel mag
mag alleen worden gebruikt onmiddellijk na een ref-naam en de ref moet een bestaand logbestand hebben
($GIT_DIR/logs/). Houd er rekening mee dat hiermee de staat van uw wordt opgezocht lokaal ref op een gegeven
tijd; bijvoorbeeld wat er in uw lokale versie stond meester filiaal vorige week. Als je wilt kijken
commits gemaakt tijdens bepaalde tijden, zie --sinds en --tot.

@{ }, bijv meester@{1}
Een ref gevolgd door het achtervoegsel @ met een ordinale specificatie ingesloten in een accoladepaar
(bv 1 {}, 15 {}) specificeert de n-de eerdere waarde van die ref. Bijvoorbeeld meester@{1}
is de onmiddellijke voorafgaande waarde van meester en meester@{5} is de 5e voorafgaande waarde van
meester. Dit achtervoegsel mag alleen direct na een ref-naam worden gebruikt en de ref moet
een bestaand logboek hebben ($GIT_DIR/logs/).

@{ }, bijv @{1}
U kunt gebruik maken van de @ construeer met een leeg ref-gedeelte om bij een reflog-invoer van de te komen
huidige tak. Bijvoorbeeld als u op een filiaal zit blabla harte @{1} betekent hetzelfde als
blabla@{1}.

@{- }, bijv @{-1}
de constructie @{- } betekent de De branch/commit is vóór de huidige uitgecheckt
een.

@{stroomopwaarts}, bijv meester@{upstream}, @{u}
Het achtervoegsel @{stroomopwaarts} naar een branchnaam (korte vorm @{u}) verwijst naar de
branch waarop de branch gespecificeerd door branchname is ingesteld om bovenop te bouwen (configured
met tak. .op afstand en filiaal. .samenvoegen). Een ontbrekende branchnaam is standaard
de huidige.

@{duw}, bijv meester@{push}, @{duw}
Het achtervoegsel @{duw} rapporteert de branch "waar we naartoe zouden pushen" als git push zou worden uitgevoerd
terwijl branchname was uitgecheckt (of de huidige HEAD als er geen branchnaam is opgegeven).
Omdat onze pushbestemming zich in een externe repository bevindt, rapporteren we uiteraard de lokale
tracking branch die correspondeert met die branch (dat wil zeggen, iets in refs/afstandsbedieningen/).

Hier is een voorbeeld om het duidelijker te maken:

$ git config push.default huidige
$ git config remote.pushdefault myfork
$ git checkout -b mijnbranch origin/master

$ git rev-parse --symbolische-volledige-naam @{upstream}
refs/afstandsbedieningen/origin/master

$ git rev-parse --symbolische-volledige-naam @{push}
refs/remotes/myfork/mybranch

Merk op dat we in het voorbeeld een driehoekige workflow hebben opgezet, waarbij we er één uit halen
locatie en duw naar een andere. In een niet-driehoekige workflow @{duw} is hetzelfde als
@{stroomopwaarts}, en dat is niet nodig.

^, bijv HOOFD^, v1.5.1^0
een achtervoegsel ^ naar een revisieparameter betekent de eerste ouder van dat commit-object. ^
betekent de de ouder (bijv ^ is gelijk aan ^1). Als bijzondere regel geldt
^0 betekent de commit zelf en wordt gebruikt wanneer is de objectnaam van een tag
object dat verwijst naar een commit-object.

~, bijv meester~3
een achtervoegsel ~ naar een revisieparameter betekent het commit-object dat de e
generatie voorouder van het genoemde commit-object, waarbij alleen de eerste ouders worden gevolgd. D.w.z
~3 is gelijk aan ^^^ wat gelijk is aan ^1^1^1. Zie hieronder voor een
illustratie van het gebruik van dit formulier.

^{ }, bijv v0.99.8^{vastlegging}
een achtervoegsel ^ gevolgd door een objecttypenaam tussen accolades, betekent dereferentie
het voorwerp bij recursief tot een object van type wordt gevonden of het object
er kan niet meer naar worden verwezen (in dat geval barf). Bijvoorbeeld als is een
commit-achtig, ^{commit} beschrijft het corresponderende commit-object. Op dezelfde manier, als
is een boomachtige, ^{boom} beschrijft het overeenkomstige boomobject. ^0 is
een afkorting voor ^{commit}.

rev^{object} kan worden gebruikt om er zeker van te zijn rev benoemt een object dat bestaat, zonder
vereisen rev als tag, en zonder dereferentie rev; omdat een tag al een
object, er hoeft niet eens een dereferentie van te worden gemaakt om bij een object te komen.

rev^{tag} kan worden gebruikt om daarvoor te zorgen rev identificeert een bestaand tagobject.

^{}, bijv v0.99.8^{}
een achtervoegsel ^ gevolgd door een leeg accoladepaar betekent dat het object een tag zou kunnen zijn, en
derefereer de tag recursief totdat een niet-tagobject wordt gevonden.

^{/ }, bijv HOOFD^{/repareren smerig beestje}
een achtervoegsel ^ naar een revisieparameter, gevolgd door een accoladepaar dat een tekst-led bevat
door een schuine streep, is hetzelfde als de :/repareren smerig kever onderstaande syntaxis, behalve dat het de
jongste overeenkomende commit die bereikbaar is via de vaardigheden ^.

:/, bijv :/repareren smerig kever
Een dubbele punt, gevolgd door een schuine streep, gevolgd door een tekst, geeft een commit aan waarvan het commit-bericht is verzonden
komt overeen met de opgegeven reguliere expressie. Deze naam retourneert de jongste overeenkomende naam
commit die bereikbaar is vanaf elke ref. Als het commit-bericht begint met een ! u
moet dat herhalen; de speciale volgorde :/!, gevolgd door iets anders dan !Is
voorlopig gereserveerd. De reguliere expressie kan overeenkomen met elk deel van het commit-bericht. Naar
match berichten die beginnen met een string, je kunt bijvoorbeeld gebruiken :/^ foe.

:, bijv HOOFD: LEESMIJ, :LEESMIJ, meester:./README
een achtervoegsel : gevolgd door een pad noemt de klodder of boom op het gegeven pad in de boom
object genoemd door het gedeelte vóór de dubbele punt. :pad (met een leeg gedeelte vóór de
dubbele punt) is een speciaal geval van de syntaxis die hierna wordt beschreven: inhoud opgenomen in de index
op het aangegeven pad. Een pad dat begint met ./ or .. / is relatief ten opzichte van de huidige werking
map. Het gegeven pad zal worden geconverteerd zodat het relatief is ten opzichte van de wortel van de werkende boom
map. Dit is vooral handig om een ​​blob of boom aan te pakken vanuit een commit of boom die
heeft dezelfde boomstructuur als de werkboom.

: :, bijv :0:LEESMIJ, :LEESMIJ
Een dubbele punt, eventueel gevolgd door een stadiumnummer (0 t/m 3) en een dubbele punt, gevolgd door een
path, noemt een blob-object in de index op het opgegeven pad. Een ontbrekend etappenummer (en
de dubbele punt die erop volgt) noemt een vermelding in fase 0. Tijdens een samenvoeging is fase 1 de
gemeenschappelijke voorouder, fase 2 is de versie van de doelvertakking (meestal de huidige
branch), en fase 3 is de versie van de branch die wordt samengevoegd.

Hier is een illustratie van Jon Loeliger. Beide commitknooppunten B en C zijn ouders van commit
knooppunt A. Bovenliggende commits worden van links naar rechts geordend.

GHIJ
\ / \ /
DEF
\ | / \
\ | / |
\|/ |
BC
\/
\/
A

EEN = = EEN ^ 0
B = A^ = A^1 = A~1
C = EEN ^ 2 = EEN ^ 2
D = EEN^^ = EEN^1^1 = EEN~2
E=B^2=A^^2
F=B^3=A^^3
G = A^^^ = A^1^1^1 = A~3
H = D^2 = B^^2 = A^^^2 = A~2^2
Ik = F^ = B^3^ = A^^3^
J = F^2 = B^3^2 = A^^3^2

SPECIFICEREN: BEREIKEN

Commando's die de geschiedenis doorkruisen, zoals git log, werken op een set commits, niet slechts op één enkele
verbinden. Voor deze opdrachten wordt één enkele revisie opgegeven met de notatie die wordt beschreven in de
vorige sectie betekent de reeks commits die bereikbaar zijn vanuit die commit, volgend op de commit
voorouders keten.

Om commits uit te sluiten die bereikbaar zijn via een commit, een voorvoegsel ^ notatie wordt gebruikt. Bijv ^ r1 r2 middel
commits bereikbaar vanaf r2 maar sluit degenen uit die bereikbaar zijn r1.

Deze ingestelde bewerking komt zo vaak voor dat er een afkorting voor bestaat. Wanneer je er twee hebt
begaat r1 en r2 (genoemd volgens de syntaxis die hierboven is uitgelegd in REVISIES SPECIFICEREN),
je kunt om commits vragen die bereikbaar zijn vanaf r2, met uitzondering van de commits die bereikbaar zijn vanaf
r1 door ^ r1 r2 en het kan worden geschreven als r1..r2.

Een soortgelijke notatie r1...r2 heet symmetrisch verschil van r1 en r2 en wordt gedefinieerd als
r1 r2 --niet $(git samenvoegbasis --alle r1 r2). Het is de reeks commits die bereikbaar zijn
van een van beide r1 or r2 maar niet van beide.

In deze twee afkortingen kunt u één uiteinde weglaten en dit standaard op HEAD laten staan. Bijvoorbeeld,
oorsprong.. is een afkorting voor oorsprong..HOOFD en vraagt: "Wat heb ik gedaan sinds ik van de
oorsprong tak?" Op dezelfde manier, ..oorsprong is een afkorting voor HOOFD..oorsprong en vraagt: "Wat deed de
oorsprong doen sinds ik ervan afsplitste?" Merk dat op .. zou betekenen HOOFD..HOOFD wat een lege is
bereik dat zowel bereikbaar als onbereikbaar is vanaf HEAD.

Twee andere afkortingen voor het benoemen van een set die wordt gevormd door een commit en zijn bovenliggende commits
bestaan. De r1^@ notatie betekent alle ouders van r1. r1^! omvat commit r1 maar sluit alles uit
van zijn ouders.

Om samen te vatten:


Inclusief commits die bereikbaar zijn vanaf (dat wil zeggen voorouders van) .

^
Sluit commits uit die bereikbaar zijn vanaf (dat wil zeggen voorouders van) .

..
Neem commits op die bereikbaar zijn vanaf maar sluit degenen uit die bereikbaar zijn
van . Wanneer ook of wordt weggelaten, is dit standaard het geval HEAD.

...
Neem commits op die vanuit beide bereikbaar zijn of maar sluit degenen uit die dat wel doen
zijn vanaf beide bereikbaar. Wanneer ook of wordt weggelaten, is dit standaard het geval HEAD.

^@, bijv HOOFD^@
een achtervoegsel ^ gevolgd door een apenstaartje is hetzelfde als het vermelden van alle ouders van
(wat betekent dat je alles opneemt dat bereikbaar is via de ouders, maar niet de commit zelf).

^!, bijv HOOFD^!
een achtervoegsel ^ gevolgd door een uitroepteken is hetzelfde als commit geven en
al zijn ouders voorafgegaan door ^ om hen (en hun voorouders) uit te sluiten.

Hier zijn een handvol voorbeelden:

DGHD
DFGHIJDF
^GDHD
^DBEIJFB
B..CC
B...CGDEBC
^DBCEIJFBC
CIJFC
C^@IJF
C^! C
F^! DHDDF

PARSEOPT

In --parseopt-modus, git rev-ontleed helpt bij het masseren van opties om scripts naar shell te brengen
dezelfde faciliteiten die C-inbouwapparaten hebben. Het werkt als een optie-normalisator (bijvoorbeeld splits single
schakelt over naar geaggregeerde waarden), een beetje zoals opt(1) doet.

Het neemt de standaardinvoer over, de specificatie van de opties om te ontleden en te begrijpen,
en echo's op de standaarduitvoer waar een string geschikt voor is sh(1) eval om de te vervangen
argumenten met genormaliseerde argumenten. In geval van een fout wordt het gebruik van de standaardfout uitgevoerd
stream en sluit af met code 129.

Opmerking: zorg ervoor dat u het resultaat citeert wanneer u het doorgeeft aan eval. Zie hieronder voor een voorbeeld.

Invoer Formaat
git rev-ontleed --parseopt invoerformaat is volledig op tekst gebaseerd. Het bestaat uit twee delen, gescheiden door
een regel die alleen -- bevat. De regels vóór het scheidingsteken (moeten er één of meer zijn) zijn dat wel
gebruikt voor het gebruik. De regels na het scheidingsteken beschrijven de opties.

Elke regel met opties heeft dit formaat:

* ? SP+ hulp LF


het formaat is het korte optieteken, gevolgd door de lange optienaam, gescheiden door een
komma. Beide delen zijn niet vereist, hoewel er minstens één nodig is. Mag niet bevatten
elk van de karakters. h,help, dry-run en f zijn voorbeelden van correct
.


zijn van *, =, ? of !.

· Gebruik = als de optie een argument nodig heeft.

· Gebruik ? om aan te geven dat de optie een optioneel argument aanneemt. Waarschijnlijk wil je dat wel
gebruik de --stuck-long modus om het optionele argument ondubbelzinnig te kunnen ontleden.

· Gebruik * om aan te geven dat deze optie niet moet worden vermeld in het gebruik dat voor de wordt gegenereerd
-h-argument. Het wordt getoond voor --help-all zoals gedocumenteerd in gitcli(7).

· Gebruik ! om de corresponderende genegeerde long-optie niet beschikbaar te stellen.


, indien opgegeven, wordt gebruikt als naam van het argument in de helpuitvoer, for
opties waar argumenten voor nodig zijn. wordt beëindigd door de eerste witruimte. Het is
Het is gebruikelijk om een ​​streepje te gebruiken om woorden te scheiden in een argumenthint die uit meerdere woorden bestaat.

De rest van de regel, na het strippen van de spaties, wordt gebruikt als hulpstuk
de optie.

Lege regels worden genegeerd en regels die niet aan deze specificatie voldoen, worden als optie gebruikt
groepskoppen (begin de regel met een spatie om dergelijke regels expres te creëren).

Voorbeeld
OPTS_SPEC="\
een commando [opties] ...

een commando doet foo en bar!
--
H, help de hulp te tonen

foo een handige optie --foo
bar= een coole optie --bar met een argument
baz=arg nog een coole optie --baz met een benoemd argument
qux?path qux kan een padargument hebben, maar heeft op zichzelf betekenis

Een optiegroepkop
C? optie C met een optioneel argument"

eval "$(echo "$OPTS_SPEC" | git rev-parse --parseopt -- "$@" || echo exit $?)"

Gebruik tekst
Wanneer "$@" in het bovenstaande voorbeeld -h of --help is, wordt de volgende gebruikstekst weergegeven:

gebruik: een commando [opties] ...

een commando doet foo en bar!

-h, --help laat de hulp zien
--foo een handige optie --foo
--bar ... een coole optie --bar met een argument
--baz nog een coole optie --baz met een benoemd argument
--qux[= ] qux kan een padargument aannemen, maar heeft op zichzelf betekenis

Een optiegroepkop
-C[...] optie C met een optioneel argument

SQ-QUOTE

In --sq-quote-modus, git rev-ontleed echo's op de standaarduitgang waar een enkele regel geschikt voor is
sh(1) evaluatie. Deze regel wordt gemaakt door de argumenten na --sq-quote te normaliseren. Niets
anders dan het citeren van de argumenten is gedaan.

Als u wilt dat de commando-invoer nog steeds zoals gebruikelijk wordt geïnterpreteerd door git rev-ontleed voor de
de uitvoer is shell-geciteerd, zie de --sq optie.

Voorbeeld
$ cat >uw-git-script.sh <<\EOF
#!/ Bin / sh
args=$(git rev-parse --sq-quote "$@") # quote door de gebruiker opgegeven argumenten
command="git frotz -n24 $args" # en gebruik het in een handgemaakt
# opdrachtregel
evalueer "$command"
EOF

$ sh jouw-git-script.sh "a b'c"

Voorbeelden

· Druk de objectnaam van de huidige commit af:

$ git rev-parse --verify HEAD

· Druk de commit-objectnaam van de revisie af in de shell-variabele $REV:

$ git rev-parse --verify $REV^{commit}

Dit geeft een foutmelding als $REV leeg is of geen geldige revisie is.

· Vergelijkbaar met hierboven:

$ git rev-parse --default master --verify $REV

maar als $REV leeg is, zal de commit-objectnaam van master worden afgedrukt.

GIT

Een deel van de git(1) Suite

Gebruik git-rev-parse online met behulp van onworks.net-services