git-rev-parse - Online nel cloud

PROGRAMMA:

NOME

git-rev-parse - Seleziona e massaggia i parametri

SINOSSI

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

DESCRIZIONE

Molti comandi in porcellana di Git accettano un misto di flag (cioè 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
comando viene utilizzato per distinguerli.

VERSIONI

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

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

--quota-quadrata
Usa il git rev-analizzare in modalità quotazione shell (vedere la sezione SQ-QUOTE di seguito). In contrasto con
l'opzione --sq sotto, questa modalità fa solo virgolette. Non si fa altro per comandare
ingresso.

Opzioni per --parseopt
--keep-trattino
Significativo solo in modalità --parseopt. Dice all'analizzatore di opzioni di echeggiare il primo --
incontrato invece di saltarlo.

--stop-at-non-opzione
Significativo solo in modalità --parseopt. Lascia che l'analizzatore di opzioni si fermi alla prima
argomento di non opzione. Questo può essere usato per analizzare i sottocomandi che accettano opzioni
loro stessi.

--bloccato-lungo
Significativo solo in modalità --parseopt. Emetti le opzioni nella loro forma lunga se
disponibili e con i loro argomenti bloccati.

Opzioni per Filtraggio
--solo giri
Non emettere flag e parametri non pensati per git rev-lista comando.

--no-giri
Non emettere flag e parametri destinati a git rev-lista comando.

--flag
Non emettere parametri senza flag.

--no-flag
Non emette parametri flag.

Opzioni per Uscita
--predefinito
Se non ci sono parametri forniti dall'utente, utilizzare Invece.

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

Questo può essere usato per convertire gli argomenti in un comando eseguito in una sottodirectory in modo che
può ancora essere utilizzato dopo essere passato al livello superiore del repository. Per 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 raw
SHA-20 a 1 byte che può essere utilizzato per accedere al database degli oggetti. Se è così, emettilo al
uscita standard; in caso contrario, errore fuori.

Se vuoi assicurarti che l'output nomi effettivamente un oggetto nel tuo oggetto
database e/o può essere utilizzato come tipo specifico di oggetto richiesto, è possibile aggiungere il
^{type} operatore peeling al parametro. Ad esempio, git rev-parse "$VAR^{commit}"
farà in modo che $VAR nomi un oggetto esistente che sia un commit (cioè un commit, o
un tag annotato che punta a un commit). Per assicurarti che $VAR nomi un esistente
oggetto di qualsiasi tipo, git rev-parse "$VAR^{oggetto}" può essere usato.

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

--q
Solitamente l'output è composto da una riga per flag e parametro. Questa opzione rende l'output a
singola linea, opportunamente quotata per il consumo a conchiglia. Utile quando ti aspetti il ​​tuo
parametro per contenere spazi bianchi e nuove righe (ad esempio quando si usa il piccone -S con git
diff-*). A differenza dell'opzione --sq-quote, l'input del comando è ancora interpretato
come al solito.

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

--abbrev-ref[=(rigoroso|sciolto)]
Un nome breve non ambiguo del nome degli oggetti. 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, prova ad abbreviarli in
un nome univoco più breve. Quando non viene specificata alcuna lunghezza, viene utilizzato 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 rende output in una forma il più vicino possibile all'input originale.

--nome-completo-simbolico
Questo è simile a --symbolic, ma omette gli input che non sono ref (cioè branch o
nomi dei tag; o più esplicitamente disambiguante forma "teste/master", quando vuoi
nominare il ramo "master" quando c'è un tag sfortunatamente chiamato "master") e mostra
come refname completi (es. "refs/heads/master").

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

--rami[=schema], --tags[=schema], --remotes[=schema]
Mostra tutti i rami, i tag o i rami di monitoraggio remoto, rispettivamente (cioè, i riferimenti trovati
rispettivamente in refs/heads, refs/tag o refs/remoti).

Se viene fornito un modello, vengono mostrati solo i riferimenti che corrispondono al dato glob di shell. Se la
pattern non contiene un carattere globbing (?, * o [), viene trasformato in un prefisso
match aggiungendo /*.

--glob=schema
Mostra tutti i riferimenti che corrispondono al modello di pattern glob shell. Se il modello non si avvia
con refs/, questo viene anteposto automaticamente. Se il modello non contiene a
carattere globbing (?, * 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. Il deve essere a
almeno 4 cifre esadecimali per evitare di elencare ogni singolo oggetto nel
deposito per errore.

Opzioni per File
--local-env-vars
Elenca le variabili d'ambiente GIT_* che sono locali al repository (es. 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 sentiero
mostrato, quando relativo, è relativo alla directory di lavoro corrente.

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

--git-dir-comune
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".

--è-dentro-l'albero-di-lavoro
Quando la directory di lavoro corrente è all'interno dell'albero di lavoro del repository stampa
"vero", altrimenti "falso".

--is-bare-repository
Quando il repository è nudo, 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 quindi risolto
viene stampato il percorso del repository reale.

--git-percorso
Risolvi "$GIT_DIR/ " e accetta altre variabili di rilocazione 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.

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

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

--show-toplevel
Mostra il percorso assoluto della directory di primo livello.

--percorso-indice-condiviso
Mostra il percorso del file di indice condiviso in modalità indice diviso o vuoto se non in
modalità a indice diviso.

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

--until=stringa data, --before=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 an SHA-1 sintassi. Qui ci sono vari modi per scrivere i nomi degli oggetti. Il
quelli elencati vicino alla fine di questo elenco nominano alberi e BLOB contenuti in un commit.

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

, per esempio v1.7.4.2-679-g3bee7fb
Output da git descrivere; cioè un tag più vicino, facoltativamente seguito da un trattino e a
numero di commit, seguito da un trattino, a ge un nome oggetto abbreviato.

, per esempio Mastercard, capi/maestro, arbitri/teste/master
Un nome di riferimento simbolico. Per esempio Mastercard in genere significa l'oggetto commit a cui fa riferimento
arbitri/teste/master. Se ti capita di avere entrambi capi/maestro ed tag/master, puoi
dire esplicitamente capi/maestro per dire a Git quale intendi. Quando ambiguo, a
è disambiguato prendendo la prima corrispondenza nelle seguenti regole:

1. Se $GIT_DIR/ esiste, questo è ciò che intendi (di solito è utile solo
per TESTA, FETCH_HEAD, TESTA_ORIG, UNISCI_TESTA ed CHERRY_PICK_HEAD);

2. altrimenti, ref/ se esiste;

3. altrimenti, riferimenti/tag/ se esiste;

4. altrimenti, arbitri/teste/ se esiste;

5. altrimenti, ref/telecomandi/ se esiste;

6. altrimenti, ref/telecomandi/ /TESTA se esiste.

TESTA nomina il commit su cui hai basato le modifiche nell'albero di lavoro.
FETCH_HEAD registra il ramo che hai scaricato da un repository remoto con il tuo
ultima chiamata di git fetch. TESTA_ORIG è creato da comandi che spostano 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 prima di correre
Loro. UNISCI_TESTA registra i commit che stai unendo nel tuo ramo
quando esegui git merge. CHERRY_PICK_HEAD registra il commit che sei
cherry-picking quando esegui git cherry-pick.

Si noti che nessuno dei rif/* i casi di cui sopra possono provenire sia dal $DIR_GIT/rif
directory o dal $ GIT_DIR/riferimenti-impaccati file. Mentre la codifica del nome di riferimento è
non specificato, è preferibile UTF-8 poiché alcune elaborazioni di output possono assumere nomi di riferimento in
UTF-8.

@
@ da solo è una scorciatoia per TESTA.

@{ }, per esempio maestro@{ieri}, TESTA@{5 verbale fa}
Un ref seguito dal suffisso @ con una specifica della data racchiusa in una coppia di 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ò
essere utilizzato solo immediatamente dopo un nome di riferimento e il riferimento deve avere un registro esistente
($GIT_DIR/log/). Nota che questo cerca lo stato del tuo locale ref a un dato
tempo; ad esempio, cosa c'era nel tuo locale? Mastercard filiale la scorsa settimana. Se vuoi guardare
commit effettuati in determinati periodi, vedi --da ed --fino a.

@{ }, per esempio maestro@{1}
Un ref seguito dal suffisso @ con una specifica ordinale racchiusa in una coppia di parentesi graffe
(per esempio {} 1, {} 15) specifica l'n-esimo valore precedente di tale rif. Per esempio maestro@{1}
è il valore immediatamente precedente di Mastercard while maestro@{5} è il quinto valore precedente di
Mastercard. Questo suffisso può essere utilizzato solo immediatamente dopo un nome di riferimento e il riferimento deve
avere un registro esistente ($GIT_DIR/log/).

@{ }, per esempio @{1}
È possibile utilizzare il @ costruire con una parte ref vuota per ottenere una voce di reflog del
ramo attuale. Ad esempio, se sei in filiale blabla poi @{1} significa lo stesso di
blabla@{1}.

@{- }, per esempio @{-1}
il costrutto @{- } significa il th branch/commit verificato prima della corrente
uno.

@{a monte}, per esempio maestro@{a monte}, @{u}
Il suffisso @{a monte} a un nome di ramo (forma breve @{u}) si riferisce a
branch su cui il branch specificato da branchname è impostato per essere costruito sopra (configurato
con ramo. .remoto e filiale. .unione). Il nome di un ramo mancante è di default
quello attuale.

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

Ecco un esempio per renderlo più chiaro:

$ git config push.default attuale
$ git config remote.pushdefault miofork
$ git checkout -b origine/master del mio ramo

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

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

Nota nell'esempio che abbiamo impostato un flusso di lavoro triangolare, in cui estraiamo da uno
posizione e spingere in 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 indica il primo genitore di quell'oggetto commit. ^
significa il esimo genitore (cioè ^ è equivalente ^1). Come regola speciale,
^0 indica 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 indica l'oggetto commit che è il ns
antenato della generazione dell'oggetto commit denominato, che segue solo i primi genitori. Cioè
~3 è equivalente ^^^ che è equivalente a ^1^1^1. Vedi sotto per an
illustrazione dell'uso di questo modulo.

^{ }, per esempio v0.99.8^{commettere}
Un suffisso ^ seguito da un nome del tipo di oggetto racchiuso tra parentesi graffe significa dereference
l'oggetto a ricorsivamente fino a un oggetto di tipo si trova o l'oggetto
non può più essere dereferenziato (nel qual caso, barf). Ad esempio, se è un
commettere, ^{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 usato 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 deve essere dereferenziato nemmeno una volta per raggiungere un oggetto.

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

^{}, per esempio v0.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 fino a quando non viene trovato un oggetto senza tag.

^{/ }, per esempio TESTA^{/correzione brutto insetto}
Un suffisso ^ a un parametro di revisione, seguito da una coppia di parentesi graffe che contiene un led di testo
da una barra, è uguale a :/aggiustare brutto insetto sintassi sotto eccetto che restituisce il
commit di corrispondenza più giovane che è raggiungibile dal prima ^.

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

:, per esempio TESTA: LEGGIMI, :LEGGIMI, master:./LEGGIMI
Un suffisso : seguito da un percorso nomina il blob o l'albero nel percorso indicato nell'albero-ish
oggetto denominato dalla parte prima dei due punti. :il percorso (con una parte vuota prima del
due punti) è un caso speciale della sintassi descritta di seguito: contenuto registrato nell'indice
al percorso indicato. Un percorso che inizia con ./ or .. / è relativo alla lavorazione corrente
directory. Il percorso dato sarà convertito per 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 a
percorso, nomina un oggetto BLOB nell'indice in corrispondenza del percorso specificato. Un numero di tappa mancante (e
i due punti che lo seguono) nomina una voce di fase 0. Durante una fusione, la fase 1 è la
antenato comune, la fase 2 è la versione del ramo di destinazione (tipicamente la corrente
branch) e la fase 3 è la versione del ramo che viene unito.

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

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

LA = = LA^0
B = LA^ = LA^1 = LA~1
C = LA^2 = LA^2
D = LA^^ = LA^1^1 = LA~2
E = B^2 = LA^^2
F = SI^3 = LA^^3
G = LA^^^ = LA^1^1^1 = LA~3
A = D^2 = B^^2 = A^^^2 = A~2^2
io = F^ = SI^3^ = LA^^3^
J = F^2 = SI^3^2 = LA^^3^2

SPECIFICANDO GAMME

I comandi di esplorazione della cronologia come git log operano su una serie di commit, non solo su un singolo
commettere. A questi comandi, specificando una singola revisione con la notazione descritta nel
sezione precedente indica l'insieme di commit raggiungibili da quel commit, dopo il commit
catena di ascendenza.

Per escludere i commit raggiungibili da un commit, un prefisso ^ si usa la notazione. Per esempio ^r1 r2 si intende
commit raggiungibile da r2 ma escludi quelli raggiungibili da r1.

Questa operazione di set appare così spesso che c'è una scorciatoia per essa. Quando ne hai due
impegna r1 ed r2 (denominato secondo la sintassi spiegata in SPECIFYING REVISIONS sopra),
puoi chiedere commit che sono raggiungibili da r2 escludendo quelli che sono raggiungibili da
r1 da ^r1 r2 e si può scrivere come r1..r2.

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

In queste due abbreviazioni, puoi omettere un'estremità e lasciarla di default su HEAD. Per 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 hanno fatto?
origine da quando ho biforcato da loro?" Nota che .. significherebbe TESTA..TESTA che è un vuoto
raggio che è sia raggiungibile che irraggiungibile da HEAD.

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

Per riassumere:


Includere commit che sono raggiungibili da (cioè antenati di) .

^
Escludere i commit che sono raggiungibili da (cioè antenati di) .

..
Includi commit raggiungibili da ma escludi quelli che sono raggiungibili
a partire dal . Quando sia o è omesso, il valore predefinito è TESTA.

...
Includi commit raggiungibili da entrambi o ma escludi quelli che
sono raggiungibili da entrambi. Quando sia o è omesso, il valore predefinito è TESTA.

^@, per esempio TESTA^@
Un suffisso ^ seguito da un segno di chiocciola equivale a elencare tutti i genitori di
(che significa, includi qualsiasi cosa raggiungibile dai suoi genitori, ma non il commit stesso).

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

Ecco una manciata di esempi:

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

PARSEOPTA

In modalità --parseopt, git rev-analizzare aiuta le opzioni di massaggio per portare agli script di shell il
stesse strutture C builtins hanno. Funziona come un normalizzatore di opzioni (ad es. divide in singolo
cambia valori aggregati), un po' come ottenere(1) fa.

Prende sullo standard input la specifica delle opzioni per analizzare e comprendere,
ed echeggia sullo standard output una stringa adatta per sh(1) eval per sostituire il
argomenti con quelli normalizzati. In caso di errore, emette l'utilizzo sull'errore standard
stream 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. Ha due parti, separate da
una riga che contiene solo --. Le righe prima del separatore (dovrebbero essere una o più) sono
utilizzato per l'uso. Le righe dopo il separatore descrivono le opzioni.

Ogni riga di opzioni ha questo formato:

* ? SP+ aiuto LF


il suo formato è il carattere dell'opzione breve, quindi il nome dell'opzione lungo separato da a
virgola. Entrambe le parti non sono necessarie, sebbene almeno una sia necessaria. Potrebbe non contenere
nessuno dei caratteri. h,help, dry-run ef sono esempi di corretto
.


sono di *, =, ? o !.

· Usa = se l'opzione accetta un argomento.

· Utilizzo ? per indicare che l'opzione accetta un argomento opzionale. Probabilmente vuoi
usa la modalità --stuck-long per poter analizzare senza ambiguità l'argomento opzionale.

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

· Utilizzo ! per non rendere disponibile la corrispondente opzione long negata.


, se specificato, viene utilizzato come nome dell'argomento nell'output della guida, per
opzioni che accettano argomenti. termina con il primo spazio bianco. è
è consuetudine utilizzare un trattino per separare le parole in un suggerimento di argomento composto da più parole.

Il resto della riga, dopo aver tolto 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 (inizia la riga con uno spazio per creare tali righe di proposito).

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

qualche comando fa pippo e bar!
--
h, aiuto mostra l'aiuto

foo qualche opzione elegante --foo
bar= qualche opzione interessante --bar con un argomento
baz=arg un'altra opzione interessante --baz con un argomento denominato
qux?percorso qux può prendere un argomento percorso ma ha un significato da solo

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

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

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

utilizzo: qualche comando [opzioni] ...

qualche comando fa pippo e bar!

-h, --help mostra l'aiuto
--foo qualche opzione elegante --foo
--bar ... qualche opzione interessante --bar con un argomento
--baz un'altra opzione interessante --baz con un argomento denominato
--qux[= ] qux può prendere un argomento percorso ma ha un significato di per sé

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

Q-QUOTE

In modalità --quote quadrate, git rev-analizzare echi sull'uscita standard una singola linea adatta per
sh(1) val. Questa riga viene creata normalizzando gli argomenti seguenti --sq-quote. Niente
altro che citare gli argomenti è fatto.

Se vuoi che l'input del comando sia ancora interpretato come al solito da git rev-analizzare prima di
l'output è citato dalla shell, vedere l'opzione --sq.

Esempio
$ cat >your-git-script.sh <<\EOF
#!/bin/sh
args=$(git rev-parse --sq-quote "$@") # quote argomenti forniti dall'utente
command="git frotz -n24 $args" # e usalo all'interno di un prodotto artigianale
# riga di comando
eval "$comando"
EOF

$ sh your-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 di shell $REV:

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

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

· Simile a 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

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