我刚刚发现了--dirty的{{1}}选项，它看起来应该做一些非常有用的事情，即当工作树变脏时，在git describe的输出后附加一个后缀但是，在我的一些存储库中似乎并非如此：
git describe我认为这可能是因为工作目录相对于标记是脏的，但似乎也不是这样：
$ git status
# On branch 8.30
nothing to commit (working directory clean)
$ git describe --dirty
8.30rel-8-g9c1cbdb-dirty
我曾经use Mercurial曾经大量使用$ git status
# On branch 1.4
nothing to commit (working directory clean)
$ git describe --tags --dirty --long
1.4rel-0-gfedfe66-dirty
并且喜欢它的默认行为是为它报告的任何提交哈希添加hg id后缀这一事实脏存储库，因此一直在寻找+等价物，但git似乎没有按照我的预期做文件：
git describe --dirty
我误解了 --dirty[=<mark>]
Describe the working tree. It means describe HEAD and appends
<mark> (-dirty by default) if the working tree is dirty.
应该做什么，或者我没有正确使用它？
如果它有所不同，所有git存储库都通过buckminster部署，因此不涉及子模块，文件系统是--dirty共享。
更新：我发现了一个解决方法，但我完全不知道这可能会有什么影响。
如果我在回购邮件上运行nfs，那么git diff --quiet HEAD突然按预期运行：
git describe我还发现，当$ 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
将存储库报告为git describe时，dirty也显示“本地未提交的更改，未签入索引”，然后在工作中列出每个文件目录，但没有针对它们的差异，只有gitk行。
进一步更新：由于这仍然是一个问题，我最终编写了一个---- filename ----脚本，该脚本首先运行git-describe-dirty但是如果它发现存储库是脏的，在再次尝试并获取第二个结果之前运行git describe --dirty。
当迭代数百个存储库时，使用git update-index -q --refresh并且只运行最初表明它是脏的存储库的索引更新，与每次运行git describe-dirty相比节省了大量时间。 p>
答案 0 :(得分：8)
如果您运行的是git 1.7.6或更早版本，则需要在使用git update-index --refresh之前运行git describe --dirty，因为索引可能已过时。使用git diff --quiet HEAD的解决方法有效，因为“git diff”是一个瓷器命令，可能会更新索引本身。
git 1.7.7的git commit that fixes this描述了问题：
运行git describe --dirty时，应刷新索引。先前 缓存的索引会导致describe认为索引是脏的， 实际上，这只是陈旧的。
请注意，您描述的确切步骤序列不应出现此问题，因为git status会更新索引。但是我仍然认为你看到了同样的问题，因为你所描述的解决方法是匹配的。以下是我演示此问题的方法：
% git describe --tags --dirty
v1.0.0
% touch pom.xml
% git describe --tags --dirty
v1.0.0-dirty
% git status
# On branch dev
nothing to commit (working directory clean)
% git describe --tags --dirty
v1.0.0
此处运行“git status”会将索引更新为副作用并修复“git describe”输出，就像您的解决方法一样。 git 1.7.6及更早版本的正确管道修复程序将是：
% touch pom.xml
% git describe --tags --dirty
v1.0.0-dirty
% git update-index --refresh
% git describe --tags --dirty
v1.0.0
答案 1 :(得分：3)
请注意，大约一年前，还有一个有关git describe --dirty的错误修复：https://github.com/git/git/commit/a1e19004e11dcbc0ceebd92c425ceb1770e52d0b
“ git --work-tree = $ there --git-dir = $ here describe --dirty”不能正常工作，因为它没有注意用户指定的工作树的位置
在发生此错误的情况下，此处显示的解决方法不起作用，因此我们必须升级安装。截至今天（2020年2月20日），似乎尚无针对Debian buster 的修复程序，但是Debian bullseye 主要git软件包目前与buster兼容。
答案 2 :(得分：1)
Git 2.13（2017年第二季度）对--dirty旗帜的--broken旗帜略有改善，因为＆＃34; git describe --dirty＆＃34;如果无法确定是否死亡
工作树中的状态与HEAD的状态匹配（例如，已损坏
存储库或损坏的子模块）。
commit b0176ce见Stefan Beller (stefanbeller)（2017年3月21日）
（Junio C Hamano -- gitster --于2017年3月27日commit 844768a合并）
builtin/describe：介绍--broken标志
git-describe会告诉您您的版本号或错误，例如 当您在存储库之外运行它时，这可能在下载时发生 一个tar球，而不是使用git来获取源代码。为了保持此属性仅在错误输出时，不在存储库中时， 严重（子模块）错误必须降级为轻轻报告 而不是完全错误
git-describe。
要实现旗帜＆＃39; --broken＆＃39;介绍，这是相同的
静脉为＆＃39; --dirty＆＃39;但使用实际的子进程来检查肮脏。
当那个孩子意外死亡时，我们会追加-broken＆＃39;代替
＆＃39; -dirty'