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.

questionAnswers(2)

yourAnswerToTheQuestion