Gere correções simples sem qualquer diffstats.

Gere diffs com uma quantidade de <n> linhas de contexto em vez das três usuais. Implica no uso da opção --patch.

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 a predefinição retorna para a largura do terminal ou 80 colunas, caso não esteja conectada em um terminal e pode ser substituída por <largura>. A largura da parte do nome do arquivo pode ser limitada, fornecendo outra largura <largura-do-nome> após uma vírgula. A largura da parte do grafo pode ser limitada utilizando --stat-graph-width=<largura> (afeta todos os comandos que geram um grafo estatístico) ou definindo diff.statGraphWidth=<largura> (não afeta o git format-patch). Ao fornecer um terceiro parâmetro <count>, é possível limitar a saída às primeiras linhas <count>, seguidas por ... 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=arquivos,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. Implica no uso da opção --patch.

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, exiba apenas um prefixo parcial. Isso é independente da opção --full-index acima, que controla o formato da produção da saída do diff-patch. A quantidade de dígitos fora do preestabelecido pode ser especificado com a 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 requerem um tempo de processamento O(n^2) em que n é a quantidade de possíveis alvos para renomeações/cópia. Esta opção impede que a detecção da ação de renomear/cópia seja executada se a quantidade dos alvos a serem renomeados/copiados exceda o a quantidade especificada.

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.

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 nomear 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.

Exiba o contexto entre as diferenças, até a quantidade de linhas especificada, 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.

Exiba todas as funções ao redor das alterações.

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.

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 a linha Signed-off-by: (Assinada por:) à mensagem do commit, utilizando a sua identidade. Para mais informações sobre a assinatura na saída da mensagem, consulte em git-commit[1].

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 (Em resposta a) e References para fazer com que o segundo e os emails subsequentes apareçam como respostas ao primeiro. Também controla a geração do cabeçalho para a referência Message-Id.

Faça com que o primeiro e-mail (ou todos os emails com --no-thread) apareça como uma resposta ao <id da mensagem> informado, o que evita quebras dos encadeamentos provendo uma nova série dos patches.

Não inclua um patch que coincida a um commit em <until>..<since> (até..desde). Examina todos os patches acessíveis a partir de <since> (desde), mas não a partir de <until> (até), os comparará com os patches que estão sendo gerados e qualquer patch coincidente será ignorado.

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

Em vez do prefixo [PATCH] predefinido na linha assunto, utilize [<prefixo do assunto>]. Permite a nomeação útil de uma série de patches e pode ser combinado com a opção --numbered.

É um atalho --subject-prefix="RFC PATCH". O RFC significa "Solicitação de Comentários"; utilize isso ao enviar um patch experimental para que ele seja discutido em vez de um patch definitivo.

Marque a série como a <n>-ésima iteração do tópico. Os nomes dos arquivos na saída têm v<n> anexado a eles e o prefixo do assunto (a predefinição retorna para "PATCH", porém pode ser alterado através da opção --subject-prefix). Por exemplo. --reroll-count=4 pode produzir o arquivo v4-0001-add-makefile.patch que contém "Assunto: [PATCH v4 1/20] Adicione o makefile".

Adicione um cabeçalho Para: nos cabeçalhos do email. É um acréscimo a qualquer cabeçalho configurado e pode ser utilizado várias vezes. A forma negada da opção --no-to descarta todos os cabeçalhos Para: que foram adicionados até agora (seja da configuração ou da linha de comando).

Adicione um cabeçalho Cc: (Com Cópia Para) aos cabeçalhos do email. É um acréscimo a qualquer cabeçalho configurado e pode ser utilizado várias vezes. A forma negada da opção --no-cc descarta todos os cabeçalhos Cc: que foram adicionados até agora (seja 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.

Adicione um cabeçalho arbitrário aos cabeçalhos do e-mail. É um acréscimo a qualquer cabeçalho configurado e pode ser utilizado várias vezes. Por exemplo, --add-header="Organization: git-foo". O formulário negado --no-add-header descarta todos os cabeçalhos (Para:, Cc: e customizado) adicionados até agora na configuração ou na linha de comando.

Além dos patches, gere uma carta de apresentação contendo no arquivo a descrição da ramificação, o "shortlog" 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 um assistente revisor, insira um "range-diff" (consulte git-range-diff[1]) na carta de apresentação ou como um comentário do patch solitário da série de 1-patch, exibindo as diferenças entre a versão anterior da série de patches e a série atualmente sendo formatada. O previous pode ser uma única revisão informando a ponta da série anterior, caso ela compartilhe uma base comum com a série que está sendo formatada (como por exemplo,o comando git format-patch --cover-letter --range-diff=feature/v1 -3 feature/v2), ou um intervalo das revisões caso as duas versões da série sejam separadas (como por exemplo, git format-patch --cover-letter --range-diff=feature/v1~3..feature/v1 -3 feature/v2).

Ao ser utilizado com a opção --range-diff, ajuste a heurística que coincida com os commits entre as séries de patches anteriores e atuais, ajustando o custo do fator de correção entre 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 em um arquivo.

Em vez de usar .patch como o sufixo dos nomes dos arquivos gerados, utilize o sufixo especificado. Uma alternativa comum é --suffix=.txt. Deixando este campo vazio remove o sufixo .patch.

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

Não reproduza o conteúdo das alterações em arquivos binários; em vez disso, exiba um aviso que estes arquivos foram alterados. Os patches gerados utilizando esta opção não podem ser aplicados de forma adequada, porém ainda são úteis para a revisão do código.

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

Registre as informações da base da árvore que identifique a condição na qual a série de patches se aplica. Consulte a seção INFORMAÇÃO BASE DA ÁRVORE abaixo para obter detalhes. If <commit> is "auto", a base commit is automatically chosen. The --no-base option overrides a format.useAutoBase configuration.

Trate o argumento revisão como um <intervalo de revisões>, mesmo que seja apenas um único commit (que normalmente seria tratado como um <since> (desde)). Observe que os commits raiz incluídos no intervalo especificado são sempre formatadas como patches de criação, independentemente dessa flag.

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