为什么`git describe -dirty`在描述干净结帐时添加`-dirty`后缀？ [英] Why is `git describe -dirty` adding a `-dirty` suffix when describing a clean checkout?

问题描述

我刚刚发现 - 脏选项为 git describe ，它看起来应该做一些非常有用的，也就是说，当工作树很脏时，为 git describe 的输出添加一个后缀，但是在我的一些存储库中似乎并不是这样：

  $ git status 
＃在分支上8.30 
没有提交（工作目录干净）
 $ git describe --dirty 
 8.30rel-8-g9c1cbdb-dirty 
  

我认为这可能会是因为工作目录相对于标签很脏，但似乎也不是这种情况：

  $ git status 
＃在分支1.4 
没有提交（工作目录干净）
 $ git describe --tags --dirty --long 
 1.4rel -0-gfedfe66-dirty 
  

我曾经广泛使用 hg id 当我用使用Mercurial 并且喜欢这样一个事实，即默认行为是将一个 + 后缀添加到它为脏资源库报告的任何提交散列，因此一直在寻找一个 git 相当于，但是 git describe --dirty 看起来并没有达到我所期待的那样：

  --dirty [=< mark>] 
描述工作树。这意味着描述HEAD并附加
< mark> （默认情况下为-dirty），如果工作树很脏。 
  

我误解了 - 脏应该这样做，还是我没有正确使用它？

如果它有任何区别，所有的git仓库都通过 buckminster ，所以不存在子模块，文件系统是 nfs 共享。

---

更新：一个工作，但我绝对不知道如何这可能有所作为。

如果我运行 git diff --quiet HEAD 然后突然间 git describe 按照我的预期工作：

  $ git status 
＃在分支上8.30 
没有提交（工作目录清理）
 $ git describe --dirty 
 8.30rel-8 -g9c1cbdb-dirty 
 $ git diff --quiet HEAD 
 $ git describe --dirty 
 8.30rel-8-g9c1cbdb 
  

我还发现当 git describe 报告存储库为 dirty code>然后 gitk 也显示本地未提交更改，未检入到索引，然后列出工作目录中的每个文件，但没有针对它们的差异，只需 ----文件名---- 行。

---

< 进一步更新：由于这仍然是一个问题，我最终编写了一个 git-describe-dirty 脚本，该脚本首先运行 git describe --dirty 但是如果它发现版本库变脏了，请运行 git update-index -q --refresh

在迭代数百个存储库时，使用 git describe-dirty 并且仅限于运行初始状态为脏的存储库的索引更新与运行 git update-index -q --refresh;相比，可节省大量时间。 git describe --dirty 每次。

解决方案

如果您正在运行git 1.7.6或更低版本，你需要在使用 git describe --dirty 之前运行 git update-index --refresh ，因为索引可能陈旧。您使用 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 
＃在分支上开发
没有任何东西提交（工作目录清理）
％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 
  

I have just discovered the --dirty option to git describe and it looks like it should do something very useful, i.e. append a suffix to the output of git describe when the working tree is dirty, however that doesn't seem to be the case on some of my repositories:

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

I thought this might be because the working directory is dirty relative to the tag, but that doesn't seem to be the case either:

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

I used to make extensive use of hg id when I used to use Mercurial and liked the fact that it's default behaviour was to add a + suffix to any commit hash it reported for a dirty repository, so have been looking out for a git equivalent since, but git describe --dirty doesn't appear to do what I would expect given the documentation:

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

Am I misunderstanding what --dirty should do, or am I not using it correctly?

In case it makes any difference, all of the git repositories are deployed via buckminster so there are no submodules involved and the filesystem is an nfs share.

---

Update: I have discovered a work around, but I have absolutely no idea how this could possibly be making a difference.

If I run git diff --quiet HEAD on the repo then all of a sudden the git describe works as I expect:

$ 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

I also spotted that when git describe was reporting the repository as dirty then gitk also showed "Local uncommitted changes, not checked in to index" and then listed each file in the working directory, but with no diffs against them, just the ---- filename ---- lines.

---

Further update: As this continued to be a problem, I eventually wrote a git-describe-dirty script, which starts by running git describe --dirty but if it finds the repository to be dirty, runs git update-index -q --refresh before trying again and taking the second result.

When iterating through hundreds of repositories, using git describe-dirty and only running the index update for a repository which initially indicates it is dirty saves a great deal of time compared to running git update-index -q --refresh ; git describe --dirty every time.

解决方案

If you are running git 1.7.6 or earlier, you need to run git update-index --refresh before using git describe --dirty, because the index may be stale. Your workaround of using git diff --quiet HEAD works because "git diff" is a porcelain command, and probably updates the index itself.

The git commit that fixes this for git 1.7.7 describes the problem:

When running git describe --dirty the index should be refreshed. Previously the cached index would cause describe to think that the index was dirty when, in reality, it was just stale.

Note that the exact sequence of steps you describe shouldn't have this problem, because git status updates the index. But I still think you are seeing this same issue because the workaround you describe matches. Here is how I demonstrate the issue:

% 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

Here running "git status" updates the index as a side effect and fixes "git describe" output, just as with your workaround. The proper plumbing fix for git 1.7.6 and earlier would be:

% touch pom.xml
% git describe --tags --dirty
v1.0.0-dirty
% git update-index --refresh
% git describe --tags --dirty
v1.0.0

这篇关于为什么`git describe -dirty`在描述干净结帐时添加`-dirty`后缀？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！