git-rev-parse - Online na nuvem

PROGRAMA:

NOME

git-rev-parse - Escolha e modifique os parâmetros

SINOPSE

git Rev-parse [--opção] ...

DESCRIÇÃO

Muitos comandos Git porcelainish usam uma mistura de sinalizadores (ou seja, parâmetros que começam com um
traço -) e parâmetros destinados ao subjacente git lista de rev comando que eles usam internamente
e sinalizadores e parâmetros para os outros comandos que eles usam a jusante de git lista de rev. Este
comando é usado para distinguir entre eles.

OPÇÕES

Divisão de Modos
Cada uma dessas opções deve aparecer primeiro na linha de comando.

--parseopt
Use git Rev-parse no modo de análise de opção (consulte a seção PARSEOPT abaixo).

--aspas quadradas
Use git Rev-parse no modo de cotação shell (consulte a seção SQ-QUOTE abaixo). Em contraste com
a opção --sq abaixo, este modo faz apenas citações. Nada mais é feito para comandar
entrada.

Opções para --parseopt
--keep-dashdash
Somente significativo no modo --parseopt. Diz ao analisador de opções para ecoar o primeiro -
conheceu em vez de ignorá-lo.

--stop-at-non-option
Somente significativo no modo --parseopt. Permite que o analisador de opções pare no primeiro
argumento de não opção. Isso pode ser usado para analisar subcomandos que possuem opções
si mesmos.

- preso por muito tempo
Somente significativo no modo --parseopt. Produza as opções em seu formato longo se
disponíveis, e com seus argumentos presos.

Opções para Filtragem
--somente rotações
Não produza sinalizadores e parâmetros não destinados a git lista de rev comando.

--sem rotações
Não produza sinalizadores e parâmetros destinados a git lista de rev comando.

--bandeiras
Não produza parâmetros sem sinalização.

--sem sinalizadores
Não envie parâmetros de sinalização.

Opções para saída
--predefinição
Se não houver nenhum parâmetro fornecido pelo usuário, use em vez de.

--prefixo
Comporte-se como se git Rev-parse foi invocado do subdiretório do trabalho
árvore. Quaisquer nomes de arquivos relativos são resolvidos como se fossem prefixados por e será
impresso nesse formulário.

Isso pode ser usado para converter argumentos em um comando executado em um subdiretório para que eles
ainda pode ser usado após passar para o nível superior do repositório. Por exemplo:

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

--verificar
Verifique se exatamente um parâmetro é fornecido e se pode ser transformado em um
SHA-20 de 1 bytes que pode ser usado para acessar o banco de dados de objetos. Em caso afirmativo, emita-o para o
saída padrão; caso contrário, sai do erro.

Se você quiser ter certeza de que a saída realmente nomeia um objeto em seu objeto
banco de dados e / ou pode ser usado como um tipo específico de objeto de que você precisa, você pode adicionar o
^ {type} operador de peeling para o parâmetro. Por exemplo, git rev-parse "$ VAR ^ {commit}"
irá certificar-se de que $ VAR nomeia um objeto existente que é um commit-ish (ou seja, um commit, ou
uma tag anotada que aponta para um commit). Para se certificar de que $ VAR nomeia um existente
objeto de qualquer tipo, git rev-parse "$ VAR ^ {object}" pode ser usado.

-q, --quieto
Significativo apenas no modo --verify. Não produza uma mensagem de erro se o primeiro argumento
não é um nome de objeto válido; em vez disso, saia com o status diferente de zero silenciosamente. SHA-1s para
nomes de objetos válidos são impressos em stdout em caso de sucesso.

--quadrado
Normalmente, a saída é feita em uma linha por sinalizador e parâmetro. Esta opção torna a saída um
linha única, devidamente cotada para consumo por shell. Útil quando você espera seu
parâmetro para conter espaços em branco e novas linhas (por exemplo, ao usar pickaxe -S com git
diff- *) Em contraste com a opção --sq-quote, a entrada do comando ainda é interpretada
como é habitual.

--não
Ao mostrar nomes de objetos, prefixe-os com ^ e tira ^ prefixo dos nomes dos objetos
que já tem um.

--abbrev-ref [= (estrito | solto)]
Um nome abreviado não ambíguo do nome do objeto. A opção core.warnAmbiguousRefs é
usado para selecionar o modo de abreviação estrita.

--short, --short = número
Em vez de enviar os valores SHA-1 completos dos nomes dos objetos, tente abreviá-los para
um nome exclusivo mais curto. Quando nenhum comprimento é especificado, 7 é usado. O comprimento mínimo é 4.

--simbólico
Normalmente, os nomes dos objetos são produzidos na forma SHA-1 (com possível ^ prefixo); isto
opção torna a saída em um formato o mais próximo possível da entrada original.

--nome-completo-simbólico
É semelhante a --symbolic, mas omite entradas que não sejam refs (ou seja, branch ou
nomes de tag; ou mais explicitamente desambiguação da forma "heads / master", quando você quiser
nomeie o branch "master" quando houver uma tag chamada infelizmente de "master") e mostre
como refnames completos (por exemplo, "refs / heads / master").

Opções para objetos
--tudo
Mostrar todos os refs encontrados em refs /.

--branches [= padrão], --tags [= padrão], --remotes [= padrão]
Mostrar todos os branches, tags ou branches de rastreamento remoto, respectivamente (ou seja, refs encontrados
em refs / heads, refs / tags ou refs / remotes, respectivamente).

Se um padrão for fornecido, apenas as referências correspondentes ao shell glob fornecido serão mostradas. Se o
padrão não contém um caractere globbing (?, * ou [), ele é transformado em um prefixo
corresponder anexando / *.

--glob = padrão
Mostra todas as referências que combinam com o padrão do padrão shell glob. Se o padrão não começar
com refs /, isso é adicionado automaticamente. Se o padrão não contém um
caractere globbing (?, * ou [), ele é transformado em uma correspondência de prefixo anexando / *.

--exclude =
Não inclua correspondência de referências que o próximo --all, --branches, --tags,
--remotes ou --glob consideraria caso contrário. As repetições desta opção se acumulam
padrões de exclusão até o próximo --all, --branches, --tags, --remotes ou --glob
opção (outras opções ou argumentos não limpam os padrões acumulados).

Os padrões fornecidos não devem começar com refs / heads, refs / tags ou refs / remotes quando
aplicado a --branches, --tags ou --remotes, respectivamente, e eles devem começar com
refs / quando aplicado a --glob ou --all. Se um rastro /* é pretendido, deve ser dado
explicitamente.

--disambiguate =
Mostra todos os objetos cujo nome começa com o prefixo fornecido. o deve estar em
pelo menos 4 dígitos hexadecimais de comprimento para evitar listar todos e cada um dos objetos no
repositório por engano.

Opções para Arquivos
--local-env-vars
Liste as variáveis ​​de ambiente GIT_ * que são locais para o repositório (por exemplo, GIT_DIR ou
GIT_WORK_TREE, mas não GIT_EDITOR). Apenas os nomes das variáveis ​​são listados, não
seu valor, mesmo se estiverem definidos.

--git-dir
Mostra $ GIT_DIR se definido. Caso contrário, mostre o caminho para o diretório .git. O caminho
mostrado, quando relativo, é relativo ao diretório de trabalho atual.

Se $ GIT_DIR não estiver definido e o diretório atual não for detectado como estando em um Git
repositório ou árvore de trabalho imprime uma mensagem para stderr e sai com status diferente de zero.

--git-common-dir
Mostra $ GIT_COMMON_DIR se definido, senão $ GIT_DIR.

--está dentro do git-dir
Quando o diretório de trabalho atual está abaixo do diretório do repositório imprima "true",
caso contrário, "falso".

--está dentro da árvore de trabalho
Quando o diretório de trabalho atual estiver dentro da árvore de trabalho do repositório, imprima
"verdadeiro", caso contrário, "falso".

--is-bare-repositório
Quando o repositório está vazio, imprima "verdadeiro", caso contrário, "falso".

--resolve-git-dir
Verifique se é um repositório válido ou um gitfile que aponta para um repositório válido,
e imprimir a localização do repositório. Se é um gitfile então o resolvido
o caminho para o repositório real é impresso.

--git-path
Resolva "$ GIT_DIR / "e usa outras variáveis ​​de realocação de caminho, como
$ GIT_OBJECT_DIRECTORY, $ GIT_INDEX_FILE ... em conta. Por exemplo, se
$ GIT_OBJECT_DIRECTORY é definido como / foo / bar e "git rev-parse --git-path objects / abc"
retorna / foo / bar / abc.

--show-cdup
Quando o comando é invocado de um subdiretório, mostra o caminho do nível superior
diretório relativo ao diretório atual (normalmente uma sequência de "../", ou um
string vazia).

--show-prefixo
Quando o comando é invocado de um subdiretório, mostra o caminho do atual
diretório relativo ao diretório de nível superior.

--show-nível superior
Mostra o caminho absoluto do diretório de nível superior.

--caminho do índice compartilhado
Mostra o caminho para o arquivo de índice compartilhado no modo de índice dividido ou vazio se não estiver em
modo de índice dividido.

Outros Opções
--since = cadeia de dados, --after = cadeia de dados
Analise a string de data e gere o parâmetro --max-age = correspondente para git
lista de rev.

--until = datestring, --before = datestring
Analise a string de data e gere o parâmetro --min-age = correspondente para git
lista de rev.

...
Sinalizadores e parâmetros a serem analisados.

ESPECIFICANDO REVISÕES

Um parâmetro de revisão normalmente, mas não necessariamente, nomeia um objeto de confirmação. Usa
o que é chamado de opção SHA-1 sintaxe. Aqui estão várias maneiras de soletrar nomes de objetos. o
aqueles listados perto do final desta lista nomeiam árvores e blobs contidos em um commit.

, por exemplo dae86e1950b1277e545cee180551750029cfe735, dae86e
O nome completo do objeto SHA-1 (string hexadecimal de 40 bytes) ou uma substring principal que
é único no repositório. Por exemplo, dae86e1950b1277e545cee180551750029cfe735 e
dae86e nomeiam o mesmo objeto de confirmação se não houver outro objeto em seu repositório
cujo nome de objeto começa com dae86e.

, por exemplo v1.7.4.2-679-g3bee7fb
Saída de git describe; ou seja, uma marca mais próxima, opcionalmente seguida por um traço e um
número de confirmações, seguido por um travessão, um ge um nome de objeto abreviado.

, por exemplo dominar, cabeças / mestre, refs / heads / master
Um nome de referência simbólico. Por exemplo dominar normalmente significa o objeto de confirmação referenciado por
refs / heads / master. Se acontecer de você ter ambos cabeças / mestre e tags / mestre, você pode
diga explicitamente cabeças / mestre para dizer ao Git de qual você se refere. Quando ambíguo, um
é eliminado a ambiguidade ao obter a primeira correspondência com as seguintes regras:

1. E se $ GIT_DIR / existe, é isso que você quer dizer (isso geralmente é útil apenas
para CABEÇA, FETCH_HEAD, ORIG_HEAD, MERGE_HEAD e CHERRY_PICK_HEAD);

2. caso contrário, refs / se existe;

3. caso contrário, refs / tags / se existe;

4. caso contrário, refs / heads / se existe;

5. caso contrário, refs / remotes / se existe;

6. caso contrário, refs / remotes / /CABEÇA se existe.

CABEÇA nomeia o commit no qual você baseou as mudanças na árvore de trabalho.
FETCH_HEAD registra o branch que você buscou de um repositório remoto com o seu
última invocação do git fetch. ORIG_HEAD é criado por comandos que movem seu CABEÇA
de forma drástica, para registrar a posição do CABEÇA antes de sua operação, então
que você pode facilmente mudar a ponta do galho de volta para o estado anterior à execução
Eles. MERGE_HEAD registra o (s) commit (s) que você está mesclando em seu branch
quando você executa git merge. CHERRY_PICK_HEAD registra o commit que você é
colheita seletiva quando você executa o git escolha seletiva.

Observe que qualquer um dos refs / * casos acima podem vir de $ GIT_DIR / refs
diretório ou do $ GIT_DIR / pack-refs Arquivo. Enquanto a codificação do nome ref é
não especificado, UTF-8 é o preferido, pois algum processamento de saída pode assumir nomes de ref em
UTF-8.

@
@ sozinho é um atalho para CABEÇA.

@ { }, por exemplo mestre @ {ontem}, CABEÇA @ {5 minutos atrás}
Um ref seguido pelo sufixo @ com uma especificação de data entre um par de chaves
(por exemplo: {ontem}, {1 mês 2 semanas 3 dias 1 hora 1 segundo atrás} or {1979/02/26
18:30:00}) especifica o valor da ref em um momento anterior. Este sufixo pode
só deve ser usado imediatamente após um nome de ref e o ref deve ter um log existente
($ GIT_DIR / logs /) Observe que isso procura o estado de seu local ref em um dado
Tempo; por exemplo, o que estava em seu local dominar filial na semana passada. Se você quiser olhar para
commits feitos em certos momentos, veja --Desde a e --até.

@ { }, por exemplo mestre @ {1}
Um ref seguido pelo sufixo @ com uma especificação ordinal dentro de um par de chaves
(por exemplo: 1 {}, 15 {}) especifica o n-ésimo valor anterior dessa ref. Por exemplo mestre @ {1}
é o valor anterior imediato de dominar enquanto mestre @ {5} é o 5º valor anterior de
dominar. Este sufixo só pode ser usado imediatamente após um nome de ref e o ref deve
tem um log existente ($ GIT_DIR / logs /).

@ { }, por exemplo @ {1}
Você pode usar o @ construir com uma parte ref vazia para obter uma entrada reflog do
ramo atual. Por exemplo, se você estiver no ramo blabla então @ {1} significa o mesmo que
blabla @ {1}.

@ {- }, por exemplo @ {- 1}
A construção @ {- } significa o o branch / commit foi verificado antes do atual
um.

@ {upstream}, por exemplo mestre @ {upstream}, @{você}
O sufixo @ {upstream} para um nome de branch (forma abreviada @{você}) refere-se a
branch que o branch especificado por branchname está configurado para construir em cima (configurado
com ramo. .remote e ramificar. .merge). Um branchname ausente é padronizado para
o atual.

@{Empurre}, por exemplo mestre @ {push}, @{Empurre}
O sufixo @{Empurre} relata o branch "para onde faríamos push" se o git push fosse executado
enquanto o branchname foi verificado (ou o atual CABEÇA se nenhum branchname for especificado).
Uma vez que nosso destino de push está em um repositório remoto, é claro, relatamos o local
ramo de rastreamento que corresponde a esse ramo (ou seja, algo em refs / remotes /).

Aqui está um exemplo para deixar mais claro:

$ git config push.default atual
$ git config remoto.pushdefault myfork
$ git checkout -b mybranch origin / master

$ git rev-parse --symbolic-full-name @ {upstream}
refs / remotes / origin / master

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

Observe no exemplo que configuramos um fluxo de trabalho triangular, de onde extraímos de um
local e empurre para outro. Em um fluxo de trabalho não triangular, @{Empurre} é o mesmo que
@ {upstream}, e não há necessidade disso.

^, por exemplo CABEÇA ^, v1.5.1 ^ 0
Um sufixo ^ para um parâmetro de revisão significa o primeiro pai desse objeto de confirmação. ^
significa o o pai (ou seja ^ é equivalente a ^ 1) Como regra especial,
^ 0 significa o próprio commit e é usado quando é o nome do objeto de uma tag
objeto que se refere a um objeto de confirmação.

~, por exemplo mestre ~ 3
Um sufixo ~ para um parâmetro de revisão significa o objeto de confirmação que é o º
ancestral de geração do objeto commit nomeado, seguindo apenas os primeiros pais. Ou seja
~ 3 é equivalente a ^^^ que é equivalente a ^ 1 ^ 1 ^ 1. Veja abaixo um
ilustração do uso deste formulário.

^ { }, por exemplo v0.99.8 ^ {commit}
Um sufixo ^ seguido por um nome de tipo de objeto entre chaves significa desreferência
o objeto em recursivamente até um objeto do tipo é encontrado ou o objeto
não pode mais ser desreferenciado (nesse caso, barf). Por exemplo, se é um
comprometer-se, ^ {commit} descreve o objeto de confirmação correspondente. Da mesma forma, se
é uma árvore ish, ^ {árvore} descreve o objeto de árvore correspondente. ^ 0 is
uma abreviação para ^ {commit}.

rev ^ {objeto} pode ser usado para ter certeza rev nomeia um objeto que existe, sem
Exigindo rev para ser uma tag, e sem desreferenciamento rev; porque uma tag já é um
objeto, ele não precisa ser referenciado nem mesmo uma vez para chegar a um objeto.

rev ^ {tag} pode ser usado para garantir que rev identifica um objeto tag existente.

^ {}, por exemplo v0.99.8 ^ {}
Um sufixo ^ seguido por um par de chaves vazio significa que o objeto pode ser uma tag, e
desreferencie a tag recursivamente até que um objeto não tag seja encontrado.

^ {/ }, por exemplo HEAD ^ {/ fix desagradável erro}
Um sufixo ^ a um parâmetro de revisão, seguido por um par de chaves que contém um led de texto
por uma barra, é o mesmo que o :/consertar desagradável erro sintaxe abaixo, exceto que retorna o
commit mais jovem que pode ser alcançado a partir do antes ^.

: /, por exemplo :/consertar desagradável erro
Dois pontos, seguido por uma barra, seguido por um texto, nomeia um commit cuja mensagem de commit
corresponde à expressão regular especificada. Este nome retorna a correspondência mais recente
commit que está acessível a partir de qualquer ref. Se a mensagem de confirmação começar com um ! Você
tem que repetir isso; a sequência especial : /!, seguido por algo diferente de !, É
reservado por enquanto. A expressão regular pode corresponder a qualquer parte da mensagem de confirmação. Para
corresponder mensagens que começam com uma string, pode-se usar, por exemplo, : / ^ foo.

:, por exemplo CABEÇA: README, :LEIA-ME, mestre: ./ README
Um sufixo : seguido por um caminho nomeia o blob ou árvore no caminho dado na árvore-ish
objeto nomeado pela parte antes dos dois pontos. :caminho (com uma parte vazia antes do
dois pontos) é um caso especial da sintaxe descrita a seguir: conteúdo registrado no índice
no caminho fornecido. Um caminho começando com ./ or .. / é relativo ao trabalho atual
diretório. O caminho fornecido seráconvertido para ser relativo à raiz da árvore de trabalho
diretório. Isso é mais útil para lidar com um blob ou árvore de um commit ou árvore que
tem a mesma estrutura de árvore da árvore de trabalho.

: :, por exemplo : 0: README, :LEIA-ME
Dois pontos, opcionalmente seguido por um número de estágio (0 a 3) e dois pontos, seguido por um
caminho, nomeia um objeto blob no índice no caminho fornecido. Um número de estágio ausente (e
os dois pontos que o seguem) nomeia uma entrada de estágio 0. Durante uma fusão, o estágio 1 é o
ancestral comum, o estágio 2 é a versão do ramo alvo (normalmente o atual
branch), e o estágio 3 é a versão da ramificação que está sendo mesclada.

Aqui está uma ilustração de Jon Loeliger. Ambos os nós de confirmação B e C são pais de confirmação
nó A. Os commits principais são ordenados da esquerda para a direita.

GHIJ
\ / \ /
DEF
\ | /\
\ | / |
\ | / |
BC
\ /
\ /
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
G = A ^^^ = A ^ 1 ^ 1 ^ 1 = A ~ 3
H = D ^ 2 = B ^^ 2 = A ^^^ 2 = A ~ 2 ^ 2
I = F ^ = B ^ 3 ^ = A ^^ 3 ^
J = F ^ 2 = B ^ 3 ^ 2 = A ^^ 3 ^ 2

ESPECIFICANDO GAMAS

Comandos que percorrem o histórico, como git log, operam em um conjunto de commits, não apenas em um único
comprometer-se. Para esses comandos, especificando uma única revisão com a notação descrita no
seção anterior significa o conjunto de commits acessíveis a partir desse commit, após o commit
cadeia de ancestralidade.

Para excluir commits acessíveis de um commit, um prefixo ^ notação é usada. Por exemplo ^ r1 r2 significa
commits acessíveis de r2 mas exclua aqueles acessíveis de r1.

Esta operação definida aparece com tanta frequência que existe uma abreviatura para ela. Quando você tem dois
compromete-se r1 e r2 (nomeado de acordo com a sintaxe explicada em ESPECIFICANDO REVISÕES acima),
você pode pedir commits que são alcançáveis ​​de r2 excluindo aqueles que são alcançáveis ​​de
r1 por ^ r1 r2 e pode ser escrito como r1..r2.

Uma notação semelhante r1 ... r2 é chamado de diferença simétrica de r1 e r2 e é definido como
r1 r2 --não $ (git base de fusão --tudo r1 r2). É o conjunto de commits acessíveis
de qualquer um dos r1 or r2 mas não de ambos.

Nessas duas abreviações, você pode omitir uma extremidade e deixá-la como HEAD por padrão. Por exemplo,
origem.. é uma abreviatura para origem..HEAD e pergunta "O que eu fiz desde que me desviei do
ramo de origem? "Da mesma forma, ..origem é uma abreviatura para CABEÇA..origem e pergunta "O que fez o
origem desde que eu bifurcou a partir deles? "Observe que .. significaria CABEÇA ... CABEÇA que é um vazio
intervalo que é alcançável e inacessível do HEAD.

Dois outros atalhos para nomear um conjunto que é formado por um commit e seus commits pai
existir. o r1 ^ @ notação significa todos os pais de r1. r1 ^! inclui commit r1 mas exclui tudo
de seus pais.

Para resumir:


Inclui confirmações acessíveis de (ou seja, ancestrais de) .

^
Exclua commits acessíveis de (ou seja, ancestrais de) .

..
Inclui confirmações que podem ser acessadas em mas exclua aqueles que são acessíveis
a partir de . Quando ou é omitido, o padrão é CABEÇA.

...
Inclui confirmações que podem ser acessadas de qualquer ou mas exclua aqueles que
são acessíveis de ambos. Quando ou é omitido, o padrão é CABEÇA.

^ @, por exemplo CABEÇA ^ @
Um sufixo ^ seguido por um sinal de arroba é o mesmo que listar todos os pais de
(ou seja, inclui qualquer coisa que possa ser acessada por seus pais, mas não o próprio commit).

^!, por exemplo CABEÇA ^!
Um sufixo ^ seguido por um ponto de exclamação é o mesmo que dar commit e depois
todos os seus pais prefixados com ^ para excluí-los (e seus ancestrais).

Aqui estão alguns exemplos:

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

PARSEOPT

No modo --parseopt, git Rev-parse ajuda a massagear opções para trazer para scripts de shell o
mesmas instalações C builtins têm. Funciona como um normalizador de opções (por exemplo, divisões simples
muda os valores agregados), um pouco como obteropt(1) sim.

Leva na entrada padrão a especificação das opções para analisar e entender,
e ecoa na saída padrão uma string adequada para sh(1) avaliação para substituir o
argumentos com os normalizados. Em caso de erro, ele exibe o uso no erro padrão
stream e sai com o código 129.

Nota: Certifique-se de citar o resultado ao passá-lo para eval. Veja abaixo um exemplo.

Entrada Formato
git Rev-parse --parseopt o formato de entrada é totalmente baseado em texto. Possui duas partes, separadas por
uma linha que contém apenas -. As linhas antes do separador (deve ser uma ou mais) são
usado para o uso. As linhas após o separador descrevem as opções.

Cada linha de opções possui este formato:

* ? SP + ajuda LF


seu formato é o caractere de opção curto e, em seguida, o nome de opção longo separado por um
vírgula. Ambas as partes não são necessárias, embora pelo menos uma seja necessária. Não pode conter
qualquer um dos personagens. h, help, dry-run ef são exemplos de corretas
.


são de *, =,? ou !.

· Use = se a opção tiver um argumento.

· Usar ? para significar que a opção leva um argumento opcional. Você provavelmente quer
use o modo --stuck-long para poder analisar sem ambigüidade o argumento opcional.

· Use * para significar que esta opção não deve ser listada no uso gerado para o
-h argumento. É mostrado para --help-all conforme documentado em gitcli(7).

· Usar ! para não disponibilizar a opção longa negada correspondente.


, se especificado, é usado como um nome do argumento na saída de ajuda, para
opções que levam argumentos. é encerrado pelo primeiro espaço em branco. Isto é
habitual usar um travessão para separar palavras em uma dica de argumento de várias palavras.

O resto da linha, depois de eliminar os espaços, é utilizado como auxiliar associado ao
a opção.

As linhas em branco são ignoradas e as linhas que não correspondem a esta especificação são usadas como opção
cabeçalhos de grupo (inicie a linha com um espaço para criar tais linhas propositalmente).

Exemplo
OPTS_SPEC = "\
algum-comando [opções] ...

some-command faz foo e bar!
--
h, ajude a mostrar a ajuda

para alguma opção bacana --foo
bar = alguma opção legal --bar com um argumento
baz = arg outra opção legal --baz com um argumento nomeado
qux? path qux pode assumir um argumento de caminho, mas tem significado por si só

Um cabeçalho de grupo de opções
C? opção C com um argumento opcional "

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

Uso texto
Quando "$ @" for -h ou --help no exemplo acima, o seguinte texto de uso seria mostrado:

uso: algum-comando [opções] ...

some-command faz foo e bar!

-h, --help mostra a ajuda
--foo alguma opção bacana --foo
--bar ... alguma opção legal --bar com um argumento
--baz outra opção legal --baz com um argumento nomeado
--qux [= ] qux pode tomar um argumento de caminho, mas tem significado por si só

Um cabeçalho de grupo de opções
-C [...] opção C com um argumento opcional

SQ-CITAÇÃO

No modo --sq-quote, git Rev-parse ecoa na saída padrão uma única linha adequada para
sh(1) avaliação. Esta linha é feita normalizando os argumentos após --sq-quote. Nada
diferente de citar os argumentos é feito.

Se você deseja que a entrada do comando ainda seja interpretada como de costume por git Rev-parse antes de o
a saída é cotada em shell, consulte a opção --sq.

Exemplo
$ cat> your-git-script.sh << \ EOF
#!/ Bin / sh
args = $ (git rev-parse --sq-quote "$ @") # quote argumentos fornecidos pelo usuário
command = "git frotz -n24 $ args" # e use-o dentro de um
# linha de comando
eval "$ command"
EOF

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

EXEMPLOS

· Imprime o nome do objeto do commit atual:

$ git rev-parse --verify HEAD

· Imprime o nome do objeto commit da revisão na variável shell $ REV:

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

Isso irá gerar um erro se $ REV estiver vazio ou não for uma revisão válida.

· Semelhante ao anterior:

$ git rev-parse - padrão master --verify $ REV

mas se $ REV estiver vazio, o nome do objeto de confirmação do master será impresso.

GIT

Parte da git(1) suíte

Use git-rev-parse online usando serviços onworks.net