Gere correções simples sem qualquer diffstats.

Gere diffs com uma quantidade de <n> linhas de contexto em vez das três usuais.

Escreve o arquivo para um determinado arquivo em vez de stdout.

Informe o caractere que será utilizado para indicar as linhas novas, antigas ou do contexto no patch que foi gerado. Normalmente eles são +, - e ' ' respectivamente.

Ativa a heurística que altera os limites dos pedaços diferentes para facilitar a leitura dos patches. Esta é a predefinição.

Desative a heurística de recuo.

Expenda um tempo extra para garantir que o menor diferencial possível seja produzido.

Gere um diff utilizando o algoritmo "patience diff" (ou diff de paciência).

Gere um diff utilizando o algoritmo "histogram diff" (ou diff de histograma).

Gere um diff utilizando o algoritmo "anchored diff" (ou diff ancorado).

Escolha um algoritmo diff. As variantes são as seguintes:

Gera um diffstat. É predefinido que o espaço necessário será utilizado para a parte do nome do arquivo e o restante para a parte do grafo. A largura máxima tem como padrão a largura do terminal ou 80 colunas caso não esteja conectado num terminal, e pode ser substituído por <largura>. A largura da parte do nome do arquivo pode ser limitado ao fornecer outra largura <largura-do-nome> após uma vírgula ou definindo com diff.statNameWidth=<width>. A largura da parte do gráfico pode ser limitada pelo uso de --stat-graph-width=<largura> ou pela configuração de diff.statGraphWidth=<largura>. A utilização de --stat ou --stat-graph-width afeta todos os comandos que geram um gráfico estatístico, enquanto a definição diff.statNameWidth ou diff.statGraphWidth não afeta o git format-patch. Ao fornecer um terceiro parâmetro <count>, você pode limitar a saída às primeiras <count> linhas, seguidas de ... caso haja mais.

A saída de um resumo condensado das informações do cabeçalho estendido como criações ou exclusões dos arquivos ("novo" ou "desaparecido", opcionalmente "+l" se for um link simbólico) e alterações do modo ("+x" ou "-x" para adicionar ou remover um bit executável, respectivamente) no diffstat. As informações são colocadas entre a parte do nome do arquivo e a parte do grafo. Implica no uso da opção --stat.

Semelhante ao --stat, exibe a quantidade de linhas adicionadas, excluídas, em notação decimal e o nome do caminho sem abreviação, para torná-lo mais amigável à máquina. Para arquivos binários, gera dois - em vez de 0 0.

Produz apenas a última linha do formato --stat contendo a quantidade total dos arquivos modificados, assim como a quantidade de linhas adicionadas e excluídas.

Produz a distribuição da quantidade relativa de alterações para cada subdiretório. O comportamento do --dirstat pode ser customizado passando uma lista de parâmetros separados por vírgula. As predefinições são controlados pela variável de configuração diff.dirstat (veja git-config[1]). Os seguintes parâmetros estão disponíveis:

É um sinônimo para --dirstat=cumulative

É um sinônimo para --dirstat=files,<parâmetro1>,<parâmetro2>…​

Produza um resumo condensado das informações estendidas do cabeçalho, como criações, renomeações e alterações do modo.

Desative a detecção da ação de renomear, mesmo quando o arquivo de configuração seja predefinido para tanto.

Se usa ou não bolhas vazias como origem do nome.

Em vez do primeiro punhado de caracteres, exiba os nomes completos dos objetos bolha antes e depois da imagem na linha "index" ao produzir a saída no formato patch.

Além de --full-index, gere um diff binário que possa ser aplicado com o comando git-apply.

Em vez de exibir o nome completo do objeto hexadecimal com 40 bytes na produção do formato diff-raw e nas linhas do cabeçalho da árvore diff, exibe o prefixo mais curto que se refira de forma única ao objeto e que tenha até <n> hexdigits. No formato da produção da saída do diff-patch, a opção --full-index tem maior prioridade, ou seja, caso --full-index seja especificado o nome completo da bolha será exibido independente da opção --abbrev. A quantidade dos dígitos fora do preestabelecido pode ser especificado através da opção --abbrev=<n>.

Divida as alterações reescritas que foram completas em pares de exclusão e criação. Isso serve a dois propósitos:

Detecte as renomeações. Caso n seja utilizado, é a limítrofe do índice da similaridade (A quantidade de adições/exclusões comparado ao tamanho do arquivo). -M90% significa que o Git deve considerar uma ação do par de exclusão/adição para ser renomeado caso mais que 90% do arquivo não tenha sido alterado. Sem um sinal de %, a quantidade deve ser lida como uma fração, com um ponto decimal antes dele. -M5 se torna por exemplo 0.5, portanto, é o mesmo que -M50%. Da mesma forma que -M05 é o mesmo que -M5%. Para limitar a detecção para renomeações exatas, utilize -M100%. A predefinição para o índice de similaridade é 50%.

Detecte as cópias e também o que for renomeado. Consulte também --find-copies-harder. Caso n seja utilizado, ele terá o mesmo significado que -M<n>.

Por motivos de desempenho, a predefinição retorna para que a opção -C encontre as cópias apenas caso o arquivo original da cópia tenha sido modificado no mesmo conjunto de alterações. Essa flag faz com que o comando inspecione os arquivos que não modificados como candidatos à origem da cópia. Esta é uma operação muito dispendiosa em projetos grandes, portanto, utilize-a com cuidado. Tem o mesmo efeito caso a opção -C seja repetida.

Omita a imagem prévia que será excluída, ou seja, imprima apenas o cabeçalho, mas não a diferença entre a pré-imagem e /dev/null. O patch resultante não deve ser aplicado com com o comando patch ou git apply; é apenas para pessoas que desejam se concentrar em revisar o texto após a alteração. Além disso, a saída obviamente não possui informações suficientes para aplicar esse patch em sentido inverso, mesmo manualmente, daí o nome da opção.

As opções -M e -C precisa de algumas ações preliminares que podem detectar os subconjuntos das renomeações/cópias simples, seguidos por uma exaustiva porção de recursos que compara o resto de todos os destinos que ainda não foram reparados com todas as fontes relevantes. (Para as renomeações, apenas as fontes restantes que não foram pareadas são relevantes; nas cópias, todas as fontes originais são relevantes). Para N fontes e destinos, esta verificação exaustiva é O(N^2). Esta opção impede que a parte exaustiva da detecção de renomeamento/cópia seja executada caso a quantidade dos arquivos de origem/destino envolvidos exceda a quantidade definida. Caso contrário, retorna para o valor definido em diff.renameLimit. Observe que o valor 0 é tratado como ilimitado.

Controlar a ordem em que os arquivos aparecem na saída. Substitui a variável de configuração diff.orderFile (consulte git-config[1]). Para cancelar a variável diff.orderFile, utilize -O/dev/null.

Descarte os arquivos da saída antes do <arquivo> (ou seja, pule para), ou mova-os para o final da saída (ou seja, redirecione para). Estas opções foram inventadas para uso do comando git difftool e podem não ser muito úteis para outra coisa.

Com esta opção, quando executado a partir de um subdiretório do projeto, pode-se dizer para excluir as alterações fora do diretório e exibir os nomes do caminho relativos a ele. Quando não estiver em um subdiretório (em um repositório simples por exemplo), é possível definir em qual subdiretório tornar a saída relativa, utilizando um <caminho> como argumento. A opção --no-relative pode ser utilizada para contrapor ambas as opções de configuração diff.relative e a anterior --relative.

Trate todos os arquivos como texto.

Ignore o retorno do carro no final da linha durante uma comparação.

Ignore as alterações no espaço na EOL (fim da linha).

Ignore as alterações na quantidade do espaço. Ignora o espaço no final da linha e considera todas as outras sequências de um ou mais caracteres de espaço como equivalentes.

Ignore o espaço durante a comparação das linhas. Ignore as diferenças mesmo que uma linha tenha espaços quando a outra linha não tiver nenhuma.

Ignore as alterações cujas linhas estejam todas em branco.

Ignore as alterações cujas linhas coincidam com a <expressão-regular>. Esta opção pode ser usada mais de uma vez.

Exibe o contexto entre os blocos diff, até a quantidade de linhas usada, fundindo assim as que estão próximas umas das outras. A predefinição retorna para diff.interHunkContext ou 0 caso a opção de configuração não esteja definida.

Exibe toda a função como linhas de contexto para cada alteração. O nome da função é determinada da mesma maneira que o git diff lida com os pedaços do cabeçalhos do patch (consulte Definindo um cabeçalho personalizado do hunk em gitattributes[5]).

Permitir que um auxiliar diff externo seja executado. Caso um controlador diff externo seja definido com gitattributes[5], será necessário a utilização desta opção com git-log[1] e seus companheiros.

Não permitir o uso de um controladores diff externo.

Permita (ou não permita) a execução dos filtros externos para a conversão do texto durante a comparação dos arquivos binários. Para mais detalhes consulte gitattributes[5]. Como os filtros "textconv" são normalmente uma conversão unidirecional, o diff resultante é legível para as pessoas porém não pode ser aplicado. Por este motivo, é predefinido que os filtros "textconv" estejam ativos apenas para os comandos git-diff[1] e git-log[1], mas não para os comandos git-format-patch[1] ou comandos "diff" que possam ser redirecionados.

Ignore as alterações nos submódulos durante a geração dos diffs. O <quando> pode ser "none" (nenhum), "untracked" (sem monitoramento/rastreamento), "dirty" (sujo) ou "all" (todos), que é a predefinição. O "none" considera o submódulo modificado quando houver arquivos não estejam rastreados, modificados ou o seu HEAD seja diferente do commit registrado no superprojeto, pode ser utilizado para substituir qualquer configuração da opção ignore (ignorar) em git-config[1] ou gitmodules[5]. Quando o "untracked" é utilizado, os submódulos não são considerados sujos quando houver apenas um conteúdo sem rastreamento (porém o monitoramento de alterações do seu conteúdo continua) O uso de "dirty" ignora todas as alterações na árvore de trabalho dos submódulos, apenas as alterações nos commits armazenados no superprojeto são exibidos (este era o comportamento anterior até a versão 1.7.0). O uso de "all" oculta todas as alterações nos submódulos.

Exiba o prefixo da origem utilizada em vez de "a/".

Exiba o prefixo do destino utilizado em vez de "b/".

Não exiba nenhum prefixo da origem ou destino.

Use the default source and destination prefixes ("a/" and "b/"). This overrides configuration variables such as diff.noprefix, diff.srcPrefix, diff.dstPrefix, and diff.mnemonicPrefix (see git-config(1)).

Prefira um prefixo adicional em cada linha produzida.

É predefinido que as entradas adicionadas através do comando "git add -N" apareçam como uma cadeia de caracteres vazia existente com o comando "git diff" e um novo arquivo com "git diff --cached". Esta opção faz com que a entrada apareça como um novo arquivo no "git diff" e inexistente no "git diff --cached". Esta opção pode ser revertida com --ita-visible-in-index. Ambas as opções são experimentais e podem ser removidas no futuro.

Prepare os patches a partir do <n> do nível mais alto dos commits.

Utilize <dir> para armazenar os arquivos resultantes em vez do diretório de trabalho atual.

Nomeie a saída no formato [PATCH n/m], mesmo que seja com um único patch.

Nomeie a saída no formato [PATCH].

Comece a enumerar os patches a partir do <n> em vez de 1.

Os nomes dos arquivos na saída serão uma sequência numérica simples sem a primeira linha predefinida do commit anexado.

Não retire/adicione [PATCH] da primeira linha da mensagem do registro log do commit.

Adicione um trailer Signed-off-by à mensagem do commit, usando a sua identidade de committer. Consulte a opção signoff do comando git-commit[1] para obter mais informações.

Imprima todos os commits na saída padrão no formato mbox em vez de criar um arquivo individual para cada um.

Crie anexos com diversas partes/misto onde a primeira parte é a mensagem do commit e o próprio patch na segunda parte utilizando Content-Disposition: attachment.

Desative a criação de um anexo, substituindo a configuração predefinida.

Crie um anexo com diversas partes/misto onde a primeira parte é a mensagem do commit e o próprio patch na segunda parte utilizando Content-Disposition: inline.

Controla a adição dos cabeçalhos In-Reply-To e References para fazer com que o segundo e-mail e os seguintes apareçam como respostas ao primeiro. Também controla a geração do cabeçalho Message-ID para referência.

Faz com que o primeiro e-mail (ou todos os e-mails que estejam usando --no-thread) apareça como uma resposta ao <id-da-menssagem> informado, o que evita a quebra das threads para fornecer uma nova série de correções.

Não inclua uma correção que corresponda a um commit em <até>..<desde>. Isso examinará todas as correções acessíveis a partir de <desde>, mas não de <até> e os comparará com as correções que estão sendo geradas, e qualquer correção correspondente será ignorado.

Inclua as correções para os commits que não apresentam nenhuma alteração, que por predefinição, são omitidos.

Controla quais as partes da carta de apresentação serão preenchidas automaticamente utilizando ao descritivo do ramo.

Use o conteúdo do <arquivo> em vez da descrição do ramo para gerar a carta de apresentação.

Em vez do prefixo padrão [PATCH] na linha de assunto, use [<prefixo-do-assunto>]. Isso pode ser usado para nomear uma série de correções e pode ser combinado com a opção --numbered.

Em vez dos 64 bytes predefinidos, corte os nomes de arquivos gerados na saída em cerca de <n> bytes (um valor muito curto será silenciosamente aumentado para um tamanho razoável). A predefinição é o valor na variável de configuração format.filenameMaxLength ou 64, caso não esteja configurada.

Prepends the string <rfc> (defaults to "RFC") to the subject prefix. As the subject prefix defaults to "PATCH", you’ll get "RFC PATCH" by default.

Marque a série como a <n>-ésima iteração do tópico. Os nomes dos arquivos de saída têm v<n> anexado a eles, e o prefixo do assunto ("PATCH" por padrão, mas configurável através da opção --subject-prefix) tem ` v<n>` anexado a ele. Por exemplo, --reroll-count=4 pode produzir o arquivo v4-0001-add-makefile.patch que tem "Subject: [PATCH v4 1/20] Add makefile" nele. O <n> não precisa ser um número inteiro ("--reroll-count=4.4" ou "--reroll-count=4rev2" são permitidos por exemplo), mas a desvantagem de usar esse tipo de reroll-count é que o range-diff/interdiff com a versão anterior não indica exatamente com qual versão a nova iteração é comparada.

Adicione um cabeçalho To: aos cabeçalhos de e-mail. Isso se soma a qualquer cabeçalho configurado e pode ser usado várias vezes. A forma negada --no-to descarta todos os cabeçalhos To: adicionados até o momento (a partir da configuração ou da linha de comando).

Adicione um cabeçalho Cc: aos cabeçalhos de e-mail. Isso se soma a qualquer cabeçalho configurado e pode ser usado várias vezes. A forma negada --no-cc descarta todos os cabeçalhos Cc: adicionados até o momento (a partir da configuração ou da linha de comando).

Utilize ident (identidade) no cabeçalho De: de cada email do commit. Caso o ident do autor do commit não seja textualmente idêntica ao ident informado, coloque um cabeçalho De: no corpo da mensagem com o autor original. Caso nenhum ident seja informado, utilize o ident de quem fez o commit.

Com o remetente do e-mail especificado por meio da opção --from, é predefinido que, um "From:" no corpo da mensagem para identificar o verdadeiro autor do commit é adicionado na parte superior da mensagem de registro do commit se o remetente for diferente do autor. Com essa opção, o "From:" no corpo da mensagem é adicionado mesmo quando o remetente e o autor têm o mesmo nome e endereço, o que pode ajudar se o software da lista de discussão confundir a identidade do remetente. A predefinição é o valor na variável de configuração format.forceInBodyFrom.

Adiciona um cabeçalho arbitrário aos cabeçalhos do e-mail. Isso se soma a qualquer cabeçalho configurado e pode ser usado várias vezes. Por exemplo, --add-header="Organization: git-foo". A forma negada --no-add-header descarta todos os cabeçalhos (To:, Cc: e os personalizados) adicionados a partir da configuração ou da linha de comando.

Além das correções, gere um arquivo tipo carta de apresentação contendo a descrição da ramificação, o registro curto e o diffstat geral. Você pode preencher uma descrição no arquivo antes de enviá-lo.

Codifique os cabeçalhos do e-mail que possuam caracteres não ASCII com "Q-encoding" (descrito na RFC 2047), em vez de emitir os cabeçalhos de forma literal. A predefinição retorna para o valor da variável de configuração format.encodeEmailHeaders.

Como um auxílio ao revisor, insira um "interdiff" na carta de apresentação ou como um comentário único do patch de uma série de 1, exibindo as diferenças entre a versão anterior da série do patch e a série atualmente sendo formatada. previous (anterior) é uma única revisão que informa a ponta da série anterior que compartilha uma base comum com a série que está sendo formatada (git format-patch --cover-letter --interdiff=feature/v1 -3 feature/v2 por exemplo).

Como auxílio ao revisor, insira um "range-diff" (consulte git-range-diff[1]) na carta de apresentação ou como comentário da única correção de uma série de 1 correções, mostrando as diferenças entre a versão anterior da série de correções e a série que está sendo formatada no momento. previous pode ser uma única revisão nomeando a ponta da série anterior se ela compartilhar uma base comum com a série que está sendo formatada (git format-patch --cover-letter --range-diff=feature/v1 -3 feature/v2 por exemplo), ou uma faixa de revisão se ambas versões da série forem distintas (por exemplo, git format-patch --cover-letter --range-diff=feature/v1~3..feature/v1 -3 feature/v2).

Usado com --range-diff, ajusta a heurística que combina os commits entre a série anterior e a atual de patches, ajustando o fator de correção do custo de criação/exclusão. Para mais detalhes consulte git-range-diff[1]).

Adiciona as anotações (consulte git-notes[1]) para o commit depois da linha com três traços.

Adicione uma assinatura em cada mensagem produzida. De acordo com a RFC 3676, a assinatura é separada do corpo por uma linha com '-- '. Caso a opção da assinatura seja omitida, a predefinição da assinatura retorna para o número da versão do Git.

Funciona exatamente como --signature, exceto que a assinatura é lida num arquivo.

Em vez de usar .patch como sufixo para os nomes de arquivos gerados, use o sufixo especificado. Uma alternativa comum é --suffix=.txt. Deixar esse campo vazio removerá o sufixo .patch.

Não imprima os nomes dos arquivos gerados na saída padrão.

Não exiba o conteúdo das alterações em arquivos binários; em vez disso, exiba um aviso de que esses arquivos foram alterados. As correções geradas com essa opção não podem ser aplicadas corretamente, mas ainda são úteis para a revisão de código.

Gere um hash zerado no cabeçalho "From" de cada patch em vez do hash do commit.

Registre as informações da árvore base para identificar o estado ao qual a série de correções se aplica. Para mais detalhes consulte a seção INFORMAÇÕES SOBRE A ÁRVORE BASE abaixo. Se o <commit> for "auto", um commit básico será escolhido automaticamente. A opção --no-base substitui uma configuração format.useAutoBase.

Trate o argumento de revisão como um <intervalo-da-revisão>, mesmo que seja apenas um único commit (que normalmente seria tratado como um <desde>). Observe que os commits raiz incluídos no intervalo especificado são sempre formatados como correções de criação, independentemente desta opção.

Exiba o progresso dos relatórios no stderr à medida que os patches são gerados.