O git log --decorate
colocará por padrão:
- o HEAD em ciano
- os ramos remotos em vermelho
- a etiqueta em verde
e pode ser alterado por meio de color.decorate
configuração.
Mas a git log --format
não oferecem uma maneira de exibir especificamente a HEAD
ou controles remotos ou ramo: os três são exibidos por meio %d
, com uma cor possível.
Atualização de maio de 2013, conforme mencionado abaixo por Elad Shahar (voto positivo), git 1.8.3 oferece mais uma opção:
git log –format
agora exibe um %C(auto)
token que diz ao Git para usar cores ao resolver %d
(decoração), %h
(nome curto do objeto de commit), etc. para a saída do terminal.
Esta postagem do blog da Atlassian comenta que esse recurso é parte de vários outros focados em formato ( git rebase
, git count-objects
) e cores ( git branch -vv
)
Isso vem em adição ao anterior auto,reset
de 1.8.2 , que desativa automaticamente as cores quando a saída não é usada para um terminal1
%C(auto,blue)Hello%C(auto,reset)
Nota: git 2.4+ (Q2 2015) fará um trabalho melhor de redefinir a cor em torno dos nomes dos ramos.
Veja o commit 5ee8758 de Junio C Hamano ( gitster
) :
log --decorate
: não vaze a cor "confirmar" no próximo item
Em " git log --decorate
", você veria o cabeçalho de commit como este:
commit ... (HEAD, jc/decorate-leaky-separator-color)
onde " commit ... (
" é pintado color.diff.commit
, " HEAD
" in color.decorate.head
, " ,
" in color.diff.commit
, o nome do branch em color.decorate.branch
e, em
seguida, fecha " )
" em color.diff.commit
.
Se você quiser pintar o HEAD e o nome do branch local com a mesma cor do texto do corpo (talvez porque ciano e verde são muito claros em um terminal preto-sobre-branco para serem legíveis), você não precisaria dizer
[color "decorate"]
head = black
branch = black
porque você não seria capaz de reutilizar a mesma configuração em um terminal branco sobre preto. Você esperaria ingenuamente
[color "decorate"]
head = normal
branch = normal
funcionar, mas infelizmente não funciona.
Ele pinta a string " HEAD
" e o nome do ramo na mesma cor do parêntese de abertura ou vírgula entre os elementos de decoração.
Isso ocorre porque o código se esquece de redefinir a cor após imprimir o "prefixo" em sua própria cor.
Observe que o git 2.5 (2º trimestre de 2015) corrige um bug:
Veja o commit 429ad20 de Junio C Hamano ( gitster
) , 13 de maio de 2015.
(Fundido por Junio C Hamano - gitster
- no commit fd70780 , 22 de maio de 2015)
log
: não encurte nomes de decoração muito cedo
O log --decorate
aprimoramento " " no Git 2.4 que mostra o commit na ponta do branch atual, por exemplo, " HEAD -> master
", não funcionou com --decorate = full.
Git 2.9.x + (Q3 2016) corrigirá outro bug e honra color=auto
para%C(auto)
Git 2.10.2 (outubro de 2016) corrige outros bugs com commit 82b83da (29 set 2016) e commit c99ad27 (17 set 2016) por René Scharfe (``) .
(Incorporado por Junio C Hamano - gitster
- no commit 76796d4 , 28 de outubro de 2016)
pretty
: evite adicionar reset para %C(auto)
se a saída estiver vazia
Emitimos uma sequência de escape para redefinir a cor e o atributo para %C(auto)
garantir que a coloração automática seja exibida conforme pretendido.
Pare de fazer isso se o strbuf de saída estiver vazio , ou seja, quando %C(auto)
aparecer no início da string de formato, porque então não há necessidade de um reset e salvamos alguns bytes na saída.
pretty
: vamos %C(auto)
redefinir todos os atributos
Cores de reset e atributos em cima %C(auto)
para permitir controlo automático total sobre eles; caso contrário, atributos como negrito ou reverso ainda podem estar em vigor nos %C
marcadores anteriores .