Por que o `git describe -dirty` está adicionando um sufixo` -dirty` ao descrever um checkout limpo?
Eu acabei de descobrir o--dirty
opção paragit describe
e parece que deve fazer algo muito útil, isto é, acrescentar um sufixo à saída degit describe
quando a árvore de trabalho está suja, no entanto, isso não parece ser o caso em alguns dos meus repositórios:
$ git status
# On branch 8.30
nothing to commit (working directory clean)
$ git describe --dirty
8.30rel-8-g9c1cbdb-dirty
Eu pensei que isso poderia ser porque o diretório de trabalho está sujoem relação à tag, mas isso não parece ser o caso:
$ git status
# On branch 1.4
nothing to commit (working directory clean)
$ git describe --tags --dirty --long
1.4rel-0-gfedfe66-dirty
Eu costumava fazer uso extensivo dehg id
quando eu costumavause Mercurial e gostei do fato de que seu comportamento padrão era adicionar um+
sufixo para qualquer hash de commit que ele reportou para um repositório sujo, então, tem procurado por umgit
equivalente desde, masgit describe --dirty
não parece fazer o que eu esperaria, dada a documentação:
--dirty[=<mark>]
Describe the working tree. It means describe HEAD and appends
<mark> (-dirty by default) if the working tree is dirty.
Eu estou entendendo mal o que--dirty
deve fazer, ou eu não estou usando corretamente?
Caso isso faça alguma diferença, todos os repositórios git são implantados viaBuckminster então não hásubmódulos envolvido e o sistema de arquivos é umnfs
compartilhar.
Atualizar: Eu descobri um trabalho ao redor, mas eu não tenho absolutamente nenhuma idéia de como isso poderia estar fazendo a diferença.
Se eu corrergit diff --quiet HEAD
no repo então, de repente, ogit describe
funciona como eu esperava:
$ git status
# On branch 8.30
nothing to commit (working directory clean)
$ git describe --dirty
8.30rel-8-g9c1cbdb-dirty
$ git diff --quiet HEAD
$ git describe --dirty
8.30rel-8-g9c1cbdb
Eu também vi que quandogit describe
estava relatando o repositório comodirty
entãogitk
também mostrou "Mudanças não confirmadas locais, não registradas no índice" e, em seguida, listou cada arquivo no diretório de trabalho, mas sem diferenças entre eles, apenas o---- filename ----
linhas.
Atualização adicional: Como isso continuou a ser um problema, eu finalmente escrevi umgit-describe-dirty
script, que começa correndogit describe --dirty
mas se achar que o repositório está sujo, corregit update-index -q --refresh
antes de tentar novamente e pegar o segundo resultado.
Ao iterar centenas de repositórios, usandogit describe-dirty
e apenas executar a atualização de índice para um repositório que inicialmente indica que está sujo economiza muito tempo comparado à execuçãogit update-index -q --refresh ; git describe --dirty
toda vez.