8

我刚刚发现了这个--dirty选项git describe，它看起来应该做一些非常有用的事情，即git describe在工作树脏时的输出中附加一个后缀，但是在我的一些存储库中似乎并非如此：

$ git status
# On branch 8.30
nothing to commit (working directory clean)
$ git describe --dirty
8.30rel-8-g9c1cbdb-dirty

我认为这可能是因为工作目录相对于 tag很脏，但似乎也不是这样：

$ git status
# On branch 1.4
nothing to commit (working directory clean)
$ git describe --tags --dirty --long
1.4rel-0-gfedfe66-dirty

hg id当我使用 Mercurial时，我曾经广泛使用过，并且喜欢它的默认行为是为+它为脏存储库报告的任何提交哈希添加后缀，因此一直在寻找git等效的东西，但git describe --dirty没有t 似乎做了我所期望的文档：

   --dirty[=<mark>]
       Describe the working tree. It means describe HEAD and appends
       <mark> (-dirty by default) if the working tree is dirty.

我是否误解了--dirty应该做什么，或者我没有正确使用它？

万一有什么不同，所有的 git 存储库都通过buckminster部署，因此不涉及子模块，文件系统是nfs共享的。

更新：我发现了一种解决方法，但我完全不知道这可能会产生什么影响。

如果我git diff --quiet HEAD在 repo 上运行，那么突然之间就会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运行相比，使用并仅运行最初表明它是脏的存储库的索引更新可以节省大量git update-index -q --refresh ; git describe --dirty时间。

4

3 回答 3

10

如果您运行的是 git 1.7.6 或更早版本，则需要git update-index --refresh在 using 之前运行git describe --dirty，因为索引可能已过时。您使用的解决方法git diff --quiet HEAD有效，因为“git diff”是一个瓷器命令，并且可能会更新索引本身。

为 git 1.7.7修复此问题的git commit 描述了该问题：

运行 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
于 2013-07-08T23:01:47.200 回答
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 兼容。

于 2020-02-20T01:14:43.110 回答
2

Git 2.13（2017 年第 2 季度）对该--dirty标志进行了--broken一些改进，因为git describe --dirty当无法确定工作树中的状态是否与 HEAD 的状态匹配（例如损坏的存储库或损坏的子模块）时，“”会死掉。

请参阅Stefan Beller ( )的提交 b0176ce（2017 年 3 月 21 日） 。（由Junio C Hamano 合并 -- --在提交 844768a中，2017 年 3 月 27 日）stefanbeller
gitster

builtin/describe: 介绍--broken标志

git-describe告诉您当前的版本号或错误，例如，当您在存储库之外运行它时，下载 tar 球而不是使用 git 获取源代码时可能会发生这种情况。

为了保持这种只出错的特性，当不在存储库中时，必须将严重的（子模块）错误降级为温和地报告它们，而不是git-describe完全出错。

为了实现这--broken一点，引入了一个标志 ' '，它与 ' --dirty' 相同，但使用一个实际的子进程来检查脏度。当那个孩子意外死亡时，我们将附加 ' -broken' 而不是 ' -dirty'。

于 2017-04-12T21:39:09.053 回答