Question

我刚刚发现了--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>

Answer 1

如果您运行的是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

Answer 2

请注意，大约一年前，还有一个有关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兼容。

Answer 3

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'

为什么`git describe -dirty`在描述干净的结账时添加了`-dirty`后缀？

3 个答案:

`builtin/describe`：介绍`--broken`标志

为什么`git describe -dirty`在描述干净的结账时添加了`-dirty`后缀？

3 个答案:

builtin/describe：介绍--broken标志

`builtin/describe`：介绍`--broken`标志