git-rev-parse - Online nel cloud

PROGRAMMA:

NOME

git-rev-parse - Seleziona e manipola i parametri

SINOSSI

git rev-analizzare [ --opzione ] ...

DESCRIZIONE

Molti comandi Git porcelainish accettano una combinazione di flag (ad esempio parametri che iniziano con a
trattino -) e parametri destinati al sottostante git rev-lista comando che usano internamente
e flag e parametri per gli altri comandi che usano a valle di git rev-lista. Questo
Il comando viene utilizzato per distinguerli.

VERSIONI

Funzionamento Modalità
Ognuna di queste opzioni deve apparire per prima sulla riga di comando.

--parseopt
Usa il git rev-analizzare in modalità di analisi delle opzioni (vedere la sezione PARSEOPT di seguito).

--citazione quadrata
Usa il git rev-analizzare in modalità di quotazione shell (vedere la sezione SQ-QUOTE di seguito). Al contrario di
l'opzione --sq qui sotto, questa modalità esegue solo le virgolette. Non viene fatto altro al comando
ingresso.

Opzioni da --parseopt
--keep-dashdash
Significativo solo in modalità --parseopt. Indica all'analizzatore delle opzioni di ripetere il primo --
incontrato invece di saltarlo.

--stop-at-non-option
Ha senso solo in modalità --parseopt. Consente all'analizzatore delle opzioni di fermarsi al primo
argomento non opzionale. Può essere utilizzato per analizzare i sottocomandi che accettano opzioni
loro stessi.

--bloccato-lungo
Significativo solo in modalità --parseopt. Visualizza le opzioni nella loro forma estesa se
disponibili e con le loro argomentazioni bloccate.

Opzioni da Filtraggio
--solo giri
Non emettere flag e parametri non destinati a git rev-lista comando.

--nessun giro
Non emettere flag e parametri destinati a git rev-lista comando.

--flag
Non emettere parametri non flag.

--nessuna bandiera
Non emettere parametri flag.

Opzioni da Uscita
--predefinito
Se non c'è nessun parametro fornito dall'utente, utilizzare Invece.

--prefisso
Comportati come se git rev-analizzare è stato invocato dal sottodirectory del lavoro
albero. Tutti i nomi di file relativi vengono risolti come se fossero preceduti da e sarà
stampato in quella forma.

Questo può essere utilizzato per convertire gli argomenti in un comando eseguito in una sottodirectory in modo che
può essere ancora utilizzato dopo essere stato spostato al livello superiore del repository. Ad esempio:

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

--verificare
Verificare che sia fornito esattamente un parametro e che possa essere trasformato in un valore grezzo
SHA-20 a 1 byte che può essere utilizzato per accedere al database degli oggetti. In tal caso, emetterlo al
output standard; in caso contrario, errore.

Se vuoi assicurarti che l'output nomini effettivamente un oggetto nel tuo oggetto
database e/o può essere utilizzato come un tipo specifico di oggetto di cui hai bisogno, puoi aggiungere il
Operatore di peeling ^{type} al parametro. Ad esempio, git rev-parse "$VAR^{commit}"
assicurerà che $VAR nomini un oggetto esistente che è un commit-ish (ad esempio un commit, o
un tag annotato che punta a un commit). Per assicurarsi che $VAR nomini un esistente
Per oggetti di qualsiasi tipo, è possibile utilizzare git rev-parse "$VAR^{object}".

-q, --silenzioso
Ha senso solo in modalità --verify. Non visualizza un messaggio di errore se il primo argomento
non è un nome di oggetto valido; invece esci con uno stato diverso da zero in modo silenzioso. SHA-1 per
in caso di successo, i nomi degli oggetti validi vengono stampati su stdout.

--sq
Di solito l'output è una riga per flag e parametro. Questa opzione rende l'output un
singola riga, correttamente quotata per il consumo da parte della shell. Utile quando ti aspetti che il tuo
parametro per contenere spazi vuoti e nuove righe (ad esempio quando si utilizza pickaxe -S con git
diff-*). A differenza dell'opzione --sq-quote, l'input del comando viene ancora interpretato
come al solito.

--non
Quando mostri i nomi degli oggetti, anteponi loro il prefisso ^ e spogliarsi ^ prefisso dai nomi degli oggetti
che ne hanno già uno.

--abbrev-ref[=(strict|loose)]
Un nome breve non ambiguo del nome dell'oggetto. L'opzione core.warnAmbiguousRefs è
utilizzato per selezionare la modalità di abbreviazione rigorosa.

--short, --short=numero
Invece di emettere i valori SHA-1 completi dei nomi degli oggetti, provare ad abbreviarli in
un nome univoco più corto. Quando non viene specificata alcuna lunghezza, viene utilizzato il valore 7. La lunghezza minima è 4.

--simbolico
Di solito i nomi degli oggetti vengono emessi in formato SHA-1 (con possibile ^ prefisso); questo
l'opzione li fa apparire in un formato il più vicino possibile all'input originale.

--nome completo simbolico
Questo è simile a --symbolic, ma omette gli input che non sono riferimenti (ad esempio branch o
nomi di tag; o più esplicitamente disambiguando la forma "heads/master", quando si desidera
nominare il ramo "master" quando c'è un tag con nome sfortunato "master") e mostrare
come nomi di riferimento completi (ad esempio "refs/heads/master").

Opzioni da Oggetti
--tutti
Mostra tutti i riferimenti trovati in refs/.

--branches[=modello], --tags[=modello], --remotes[=modello]
Mostra tutti i rami, i tag o i rami di tracciamento remoto, rispettivamente (ad esempio, i riferimenti trovati
rispettivamente in refs/heads, refs/tags o refs/remotes).

Se viene fornito un pattern, vengono mostrati solo i riferimenti corrispondenti al glob shell specificato. Se
il pattern non contiene un carattere globbing (?, * o [), viene trasformato in un prefisso
corrisponde aggiungendo /*.

--glob=modello
Mostra tutti i riferimenti che corrispondono al pattern glob della shell. Se il pattern non inizia
con refs/, questo viene automaticamente anteposto. Se il modello non contiene un
carattere glob (?, * o [), viene trasformato in una corrispondenza di prefisso aggiungendo /*.

--exclude=
Non includere la corrispondenza dei riferimenti che il prossimo --all, --rami, --tag,
--remotes o --glob considererebbero altrimenti. Le ripetizioni di questa opzione si accumulano
pattern di esclusione fino al successivo --all, --branches, --tags, --remotes o --glob
opzione (altre opzioni o argomenti non cancellano i modelli accumulati).

I modelli forniti non dovrebbero iniziare con refs/heads, refs/tag o ref/remoti quando
applicati rispettivamente a --branches, --tags o --remotes e devono iniziare con
refs/ quando applicato a --glob o --all. Se un finale /* è inteso, deve essere dato
esplicitamente.

--disambigua=
Mostra ogni oggetto il cui nome inizia con il prefisso specificato. deve essere a
almeno 4 cifre esadecimali per evitare di elencare ogni singolo oggetto nel
repository per errore.

Opzioni da File
--variabili-ambiente-locali
Elenca le variabili di ambiente GIT_* che sono locali al repository (ad esempio GIT_DIR o
GIT_WORK_TREE, ma non GIT_EDITOR). Vengono elencati solo i nomi delle variabili, non
il loro valore, anche se sono impostati.

--git-dir
Mostra $GIT_DIR se definito. Altrimenti mostra il percorso della directory .git. Il percorso
mostrato, quando relativo, è relativo alla directory di lavoro corrente.

Se $GIT_DIR non è definito e la directory corrente non viene rilevata come situata in un Git
repository o albero di lavoro stampa un messaggio su stderr ed esce con uno stato diverso da zero.

--git-common-dir
Mostra $GIT_COMMON_DIR se definito, altrimenti $GIT_DIR.

--è-dentro-git-dir
Quando la directory di lavoro corrente è al di sotto della directory del repository, stampa "true",
altrimenti "falso".

--is-inside-work-tree
Quando la directory di lavoro corrente si trova all'interno dell'albero di lavoro del repository, stampa
"vero", altrimenti "falso".

--è-nudo-repository
Quando il repository è vuoto, stampa "true", altrimenti "false".

--resolve-git-dir
Controlla se è un repository valido o un gitfile che punta a un repository valido,
e stampare la posizione del repository. Se è un gitfile allora risolto
viene stampato il percorso al repository reale.

--git-path
Risolvi "$GIT_DIR/ " e accetta altre variabili di ricollocazione del percorso come
$GIT_OBJECT_DIRECTORY, $GIT_INDEX_FILE... in considerazione. Ad esempio, se
$GIT_OBJECT_DIRECTORY è impostato su /foo/bar, quindi "git rev-parse --git-path objects/abc"
restituisce /foo/bar/abc.

--mostra-cdup
Quando il comando viene richiamato da una sottodirectory, mostra il percorso del livello superiore
directory relativa alla directory corrente (tipicamente una sequenza di "../", o un
stringa vuota).

--mostra-prefisso
Quando il comando viene richiamato da una sottodirectory, mostra il percorso della directory corrente
directory relativa alla directory di livello superiore.

--mostra-livello superiore
Mostra il percorso assoluto della directory di livello superiore.

--percorso-indice-condiviso
Mostra il percorso al file di indice condiviso in modalità indice diviso, oppure vuoto se non è in
modalità indice diviso.

Altri Opzioni
--since=stringa data, --after=stringa data
Analizza la stringa della data e genera il parametro --max-age= corrispondente per git
rev-lista.

--fino a=stringa data, --prima=stringa data
Analizza la stringa della data e genera il parametro --min-age= corrispondente per git
rev-lista.

...
Flag e parametri da analizzare.

SPECIFICANDO REVISIONI

Un parametro di revisione in genere, ma non necessariamente, nomina un oggetto commit. Utilizza
quello che si chiama un SHA-1 sintassi. Ecco vari modi per scrivere i nomi degli oggetti. Il
quelli elencati verso la fine di questo elenco nominano gli alberi e i blob contenuti in un commit.

, per esempio dae86e1950b1277e545cee180551750029cfe735, dae86e
Il nome completo dell'oggetto SHA-1 (stringa esadecimale da 40 byte) o una sottostringa iniziale che
è univoco all'interno del repository. Ad esempio dae86e1950b1277e545cee180551750029cfe735 e
dae86e nomina entrambi lo stesso oggetto commit se non c'è nessun altro oggetto nel tuo repository
il cui nome oggetto inizia con dae86e.

, per esempio v1.7.4.2-679-g3bee7fb
Output da git describe; ovvero un tag più vicino, facoltativamente seguito da un trattino e da un
numero di commit, seguito da un trattino, un ge un nome abbreviato dell'oggetto.

, per esempio Mastercard, teste/padrone, arbitri/teste/master
Un nome di riferimento simbolico. Ad esempio Mastercard in genere significa l'oggetto commit a cui fa riferimento
arbitri/teste/masterSe ti capita di avere entrambi teste/padrone e tag/master, puoi
dire esplicitamente teste/padrone per dire a Git quale intendi. Quando è ambiguo, un
è disambiguato prendendo la prima partita nelle seguenti regole:

1. Se $GIT_DIR/ esiste, questo è ciò che intendi (di solito è utile solo
da TESTA, FETCH_HEAD, ORIG_HEAD, MERGE_HEAD e TESTA_CILIEGIA_RACCOLTA);

2. altrimenti, rif/ se esiste;

3. altrimenti, riferimenti/tag/ se esiste;

4. altrimenti, arbitri/teste/ se esiste;

5. altrimenti, riferimenti/remoti/ se esiste;

6. altrimenti, riferimenti/remoti/ /TESTA se esiste.

TESTA indica il commit su cui hai basato le modifiche nell'albero di lavoro.
FETCH_HEAD registra il ramo che hai recuperato da un repository remoto con il tuo
ultima invocazione di git fetch. ORIG_HEAD è creato da comandi che muovono il tuo TESTA
in modo drastico, per registrare la posizione del TESTA prima della loro operazione, quindi
che puoi facilmente riportare la punta del ramo allo stato precedente all'esecuzione
Loro. MERGE_HEAD registra i commit che stai unendo al tuo ramo
quando esegui git merge. TESTA_CILIEGIA_RACCOLTA registra il commit che stai eseguendo
cherry-picking quando si esegue git cherry-pick.

Nota che uno qualsiasi dei riferimenti/* i casi sopra possono provenire sia dal $GIT_DIR/refs
directory o dal $GIT_DIR/packed-refs file. Mentre la codifica del nome di riferimento è
non specificato, è preferito UTF-8 poiché alcune elaborazioni di output potrebbero assumere nomi di riferimento in
UTF-8.

@
@ da solo è una scorciatoia per TESTA.

@{ }, per esempio master@{ieri}, TESTA@{5 verbale fa}
Un riferimento seguito dal suffisso @ con una specifica della data racchiusa tra parentesi graffe
(per esempio {Ieri}, {1 mese 2 settimana 3 giorni 1 ora 1 secondo fa} or {1979-02-26
18:30:00}) specifica il valore del riferimento in un momento precedente. Questo suffisso può
può essere utilizzato solo immediatamente dopo un nome di riferimento e il riferimento deve avere un registro esistente
($GIT_DIR/logs/). Nota che questo cerca lo stato del tuo locale rif a un dato
tempo; ad esempio, cosa c'era nella tua zona Mastercard filiale la scorsa settimana. Se vuoi dare un'occhiata
impegni effettuati in determinati periodi, vedere --da e --fino a.

@{ }, per esempio maestro@{1}
Un riferimento seguito dal suffisso @ con una specificazione ordinale racchiusa tra parentesi graffe
(per esempio {} 1, {} 15) specifica l'n-esimo valore precedente di quel riferimento. Ad esempio maestro@{1}
è il valore immediatamente antecedente di Mastercard while maestro@{5} è il 5° valore a priori di
MastercardQuesto suffisso può essere utilizzato solo immediatamente dopo un nome di riferimento e il riferimento deve
avere un registro esistente ($GIT_DIR/logs/).

@{ }, per esempio @{1}
È possibile utilizzare il @ costruire con una parte ref vuota per arrivare a una voce reflog del
ramo corrente. Ad esempio, se ti trovi sul ramo blabla poi @{1} significa lo stesso di
blabla@{1}.

@{- }, per esempio @{-1}
Il costrutto @{- } significa il esimo ramo/commit verificato prima dell'attuale
uno.

@{a monte}, per esempio master@{a monte}, @{u}
Il suffisso @{a monte} a un nome di filiale (forma abbreviata @{u}) si riferisce al
ramo su cui è impostato il ramo specificato da branchname per la creazione (configurato
con ramo. .remoto e filiale. .merge). Un nome di ramo mancante è impostato di default su
quello attuale.

@{spingere}, per esempio master@{spingere}, @{spingere}
Il suffisso @{spingere} segnala il ramo "dove spingeremmo" se venisse eseguito git push
mentre branchname è stato estratto (o corrente TESTA se non viene specificato alcun nome di filiale).
Poiché la nostra destinazione push è in un repository remoto, ovviamente, segnaliamo il locale
tracciamento del ramo che corrisponde a quel ramo (ad esempio, qualcosa in ref/telecomandi/).

Ecco un esempio per chiarire meglio il concetto:

$ git config push.default corrente
$ git config remote.pushdefault myfork
$ git checkout -b mybranch origin/master

$ git rev-parse --symbolic-full-name @{upstream}
refs/remoti/origine/master

$ git rev-parse --symbolic-full-name @{push}
refs/remotes/myfork/mybranch

Nota nell'esempio che abbiamo impostato un flusso di lavoro triangolare, in cui estraiamo da uno
posizione e spingere verso un'altra. In un flusso di lavoro non triangolare, @{spingere} equivale a
@{a monte}e non ce n'è bisogno.

^, per esempio TESTA^, v1.5.1^0
Un suffisso ^ a un parametro di revisione si intende il primo genitore di quell'oggetto commit. ^
significa il esimo genitore (cioè ^ è equivalente ^1). Come regola speciale,
^0 significa il commit stesso e viene utilizzato quando è il nome dell'oggetto di un tag
oggetto che fa riferimento a un oggetto commit.

~, per esempio maestro~3
Un suffisso ~ a un parametro di revisione significa l'oggetto commit che è il il
generazione antenato dell'oggetto commit denominato, seguendo solo i primi genitori. Cioè
~3 è equivalente ^^^ che è equivalente a ^1^1^1Vedi sotto per un
illustrazione dell'utilizzo di questo modulo.

^{ }, per esempio v0.99.8^{commit}
Un suffisso ^ seguito da un nome di tipo di oggetto racchiuso tra parentesi graffe significa dereferenziazione
l'oggetto a ricorsivamente fino a quando un oggetto di tipo viene trovato o l'oggetto
non può più essere dereferenziato (nel qual caso, vomito). Ad esempio, se è un
impegnarsi-ish, ^{commettere} descrive l'oggetto commit corrispondente. Allo stesso modo, se
è un albero, ^{albero} descrive l'oggetto albero corrispondente. ^0 is
una scorciatoia per ^{commettere}.

rev^{oggetto} può essere utilizzato per assicurarsi rev nomina un oggetto che esiste, senza
richiedendo rev essere un tag e senza dereferenziare rev; perché un tag è già un
oggetto, non è necessario dereferenziarlo nemmeno una volta per arrivare a un oggetto.

rev^{tag} può essere utilizzato per garantire che rev identifica un oggetto tag esistente.

^{}, per esempio versione 0.99.8^{}
Un suffisso ^ seguito da una coppia di parentesi graffe vuote significa che l'oggetto potrebbe essere un tag e
dereferenziare il tag in modo ricorsivo finché non viene trovato un oggetto non tag.

^{/ }, per esempio TESTA^{/correggi brutto insetto}
Un suffisso ^ a un parametro di revisione, seguito da una coppia di parentesi graffe che contiene un testo led
da una barra, è lo stesso del :/aggiustare brutto insetto sintassi seguente, tranne per il fatto che restituisce il
commit corrispondente più giovane raggiungibile da prima ^.

:/, per esempio :/aggiustare brutto insetto
Due punti, seguiti da una barra, seguiti da un testo, indicano un commit il cui messaggio di commit
corrisponde all'espressione regolare specificata. Questo nome restituisce la corrispondenza più recente
commit raggiungibile da qualsiasi riferimento. Se il messaggio di commit inizia con un ! Tu
devo ripetere quella sequenza speciale :/!, seguito da qualcos'altro oltre a !, è
riservato per ora. L'espressione regolare può corrispondere a qualsiasi parte del messaggio di commit. Per
per abbinare i messaggi che iniziano con una stringa, si può usare ad esempio :/^pippo.

:, per esempio TESTA:LEGGIMI, :LEGGIMI, master:./LEGGIMI
Un suffisso : seguito da un percorso nomina il blob o l'albero nel percorso dato nell'albero-ish
oggetto denominato dalla parte prima dei due punti. :sentiero (con una parte vuota prima del
due punti) è un caso speciale della sintassi descritta di seguito: contenuto registrato nell'indice
nel percorso dato. Un percorso che inizia con ./ or .. / è relativo al lavoro corrente
directory. Il percorso specificato verrà convertito in modo da essere relativo alla radice dell'albero di lavoro
directory. Questo è molto utile per indirizzare un blob o un albero da un commit o un albero che
ha la stessa struttura ad albero dell'albero di lavoro.

: :, per esempio :0:LEGGIMI, :LEGGIMI
Due punti, facoltativamente seguiti da un numero di fase (da 0 a 3) e due punti, seguiti da un
percorso, assegna un nome a un oggetto blob nell'indice nel percorso specificato. Un numero di fase mancante (e
i due punti che lo seguono) nominano una voce di fase 0. Durante una fusione, la fase 1 è la
antenato comune, la fase 2 è la versione del ramo di destinazione (tipicamente l'attuale
branch), mentre la fase 3 è la versione del branch che viene unito.

Ecco un'illustrazione di Jon Loeliger. Entrambi i nodi di commit B e C sono genitori del commit.
nodo A. I commit padre sono ordinati da sinistra a destra.

GHIJ
\ / \ /
DEF
\ | / \
\ | / |
\|/ |
AVANTI CRISTO
\ /
\ /
A

A = = A^0
B = A^ = A^1 = A~1
C = A^2 = A^2
D = A^^ = A^1^1 = A~2
E = B^2 = A^^2
F = B^3 = A^^3
Sol = La^^^ = La^1^1^1 = La~3
H = D^2 = B^^2 = A^^^2 = A~2^2
Io = F^ = B^3^ = A^^3^
J = F^2 = B^3^2 = A^^3^2

SPECIFICANDO GAMME

I comandi di attraversamento della cronologia come git log operano su un insieme di commit, non solo su uno singolo
commit. A questi comandi, specificando una singola revisione con la notazione descritta nel
la sezione precedente indica l'insieme dei commit raggiungibili da quel commit, seguendo il commit
catena di discendenza.

Per escludere i commit raggiungibili da un commit, un prefisso ^ viene utilizzata la notazione. Ad esempio ^r1 r2 si intende
commit raggiungibili da r2 ma escludere quelli raggiungibili da r1.

Questa operazione di insieme appare così spesso che esiste una scorciatoia per definirla. Quando si hanno due
impegna r1 e r2 (denominato secondo la sintassi spiegata in SPECIFICA DELLE REVISIONI sopra),
puoi richiedere commit raggiungibili da r2 escludendo quelli raggiungibili da
r1 di ^r1 r2 e può essere scritto come r1..r2.

Una notazione simile r1...r2 si chiama differenza simmetrica di r1 e r2 ed è definito come
r1 r2 --non $(git base di unione --tutti r1 r2)È l'insieme dei commit raggiungibili
da uno qualsiasi dei r1 or r2 ma non da entrambi.

In queste due abbreviazioni, puoi omettere un'estremità e lasciare che sia HEAD per impostazione predefinita. Ad esempio,
origine.. è una scorciatoia per origine..TESTA e chiede "Cosa ho fatto da quando ho biforcato dal
ramo di origine?" Allo stesso modo, ..origine è una scorciatoia per TESTA..origine e chiede "Cosa ha fatto il
origine da quando ho biforcato da loro?" Nota che .. significherebbe TESTA...TESTA che è un vuoto
intervallo che è sia raggiungibile che irraggiungibile da HEAD.

Altre due abbreviazioni per nominare un set formato da un commit e dai suoi commit padre
esistere. Il r1^@ notazione significa tutti i genitori di r1. r1^! include commit r1 ma esclude tutti
dei suoi genitori.

Per riassumere:


Includi i commit raggiungibili da (ad esempio antenati di) .

^
Escludi i commit raggiungibili da (ad esempio antenati di) .

..
Includi i commit raggiungibili da ma escludi quelli che sono raggiungibili
da Quando uno dei due O viene omesso, il valore predefinito è TESTA.

...
Includere commit raggiungibili da entrambi O ma escludi quelli che
sono raggiungibili da entrambi. Quando uno dei due O viene omesso, il valore predefinito è TESTA.

^@, per esempio TESTA^@
Un suffisso ^ seguito da un segno di chiocciola equivale a elencare tutti i genitori di
(ovvero, includere tutto ciò che è raggiungibile dai suoi genitori, ma non il commit stesso).

^!, per esempio TESTA^!
Un suffisso ^ seguito da un punto esclamativo equivale a dare un commit e poi
tutti i suoi genitori preceduti da ^ per escluderli (e i loro antenati).

Ecco alcuni esempi:

DGHD
DFGHIJDF
^GDHD
^DBEIJFB
B..CC
B...CGHDEBC
^DBCEIJFBC
CIJFC
C^@ IJF
C^! C
F^! DGHDF

PARSEOPT

In modalità --parseopt, git rev-analizzare aiuta a massaggiare le opzioni per portare agli script shell il
stesse funzionalità dei built-in C. Funziona come un normalizzatore di opzioni (ad esempio divide singoli
commuta i valori aggregati), un po' come ottenere(1) fa.

Prende sullo standard input la specifica delle opzioni da analizzare e comprendere,
e riproduce sullo standard output una stringa adatta per sh(1) valutare di sostituire il
argomenti con quelli normalizzati. In caso di errore, restituisce l'utilizzo sull'errore standard
flusso ed esce con il codice 129.

Nota: assicurati di citare il risultato quando lo passi a eval. Vedi sotto per un esempio.

Ingresso Formato
git rev-analizzare --parseopt Il formato di input è completamente basato sul testo. È composto da due parti, separate da
una riga che contiene solo --. Le righe prima del separatore (dovrebbero essere una o più) sono
utilizzato per l'utilizzo. Le righe dopo il separatore descrivono le opzioni.

Ogni riga di opzioni ha questo formato:

* ? SP+ aiuto LF


il suo formato è il carattere di opzione breve, quindi il nome di opzione lungo separato da un
virgola. Entrambe le parti non sono obbligatorie, anche se almeno una è necessaria. Non può contenere
uno qualsiasi dei caratteri. h,help, dry-run e f sono esempi di caratteri corretti
.


sono di *, =, ? o !.

· Utilizzare = se l'opzione accetta un argomento.

· Usa ? per indicare che l'opzione accetta un argomento facoltativo. Probabilmente vuoi
utilizzare la modalità --stuck-long per poter analizzare in modo univoco l'argomento facoltativo.

· Utilizzare * per indicare che questa opzione non deve essere elencata nell'utilizzo generato per
-h argomento. Viene mostrato per --help-all come documentato in gitcli(7).

· Utilizzare ! per non rendere disponibile l'opzione lunga negata corrispondente.


, se specificato, viene utilizzato come nome dell'argomento nell'output della guida, per
opzioni che accettano argomenti. è terminato dal primo spazio vuoto. È
è consuetudine usare un trattino per separare le parole in un suggerimento di argomento composto da più parole.

Il resto della riga, dopo aver eliminato gli spazi, viene utilizzato come aiuto associato a
l'opzione.

Le righe vuote vengono ignorate e le righe che non corrispondono a questa specifica vengono utilizzate come opzione
intestazioni di gruppo (iniziare la riga con uno spazio per creare intenzionalmente tali righe).

Esempio
OPTS_SPEC="\
qualche comando [opzioni] ...

some-command fa foo e bar!
--
h,help mostra l'aiuto

foo qualche bella opzione --foo
bar= un'opzione interessante --bar con un argomento
baz=arg un'altra opzione interessante --baz con un argomento denominato
qux?path qux può accettare un argomento path ma ha un significato di per sé

Un'intestazione di gruppo di opzioni
C? opzione C con un argomento facoltativo"

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

Impiego testo
Quando "$@" è -h o --help nell'esempio precedente, verrà visualizzato il seguente testo di utilizzo:

utilizzo: some-command [opzioni] ...

some-command fa foo e bar!

-h, --help mostra la guida
--foo un'opzione interessante --foo
--bar ... un'opzione interessante --bar con un argomento
--baz un'altra opzione interessante: baz con un argomento denominato
--qux[= ] qux può accettare un argomento di percorso ma ha un significato di per sé

Un'intestazione di gruppo di opzioni
-C[...] opzione C con un argomento facoltativo

CITAZIONE QUADRATA

In modalità --sq-quote, git rev-analizzare echeggia sullo standard output una singola riga adatta per
sh(1) eval. Questa riga è realizzata normalizzando gli argomenti che seguono --sq-quote. Niente
altro che citare gli argomenti è fatto.

Se si desidera che l'input del comando venga comunque interpretato come di consueto da git rev-analizzare prima di
l'output è tra virgolette della shell, vedere l'opzione --sq.

Esempio
$ cat >il-tuo-script-git.sh <<\EOF
#!/bin/sh
args=$(git rev-parse --sq-quote "$@") # cita gli argomenti forniti dall'utente
command="git frotz -n24 $args" # e utilizzarlo all'interno di un file creato a mano
# riga di comando
eval "$comando"
EOF

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

ESEMPI

· Stampa il nome dell'oggetto del commit corrente:

$ git rev-parse --verify HEAD

· Stampa il nome dell'oggetto commit dalla revisione nella variabile shell $REV:

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

Questo genererà un errore se $REV è vuoto o non è una revisione valida.

· Simile a quanto sopra:

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

ma se $REV è vuoto, verrà stampato il nome dell'oggetto commit dal master.

GIT

Parte della git(1) seguito

Utilizzare git-rev-parse online utilizzando i servizi onworks.net