Junio C Hamano <gitster@xxxxxxxxx> writes:
> The first step would be to allow those who want their "git describe
> --dirty --ignore=none" (untracked files are counted as dirtiness, to
> be consistent with how "git diff" sees submodule directories by
> default) to use presence of untracked files as dirty. This is a
> safe first step and can be done without breaking any existing users.
It is worse than I thought. There is zero-th step we need to have,
to fix "git describe --dirty" itself.
Because the command internally uses "diff-index", and by default it
considers that a submodule with untracked path *is* dirty. Because
of that, you get an inexplicable inconsistent behaviour.
* If you start from a pristine checkout, and then add an untracked
path to the current project, "git describe --dirty" won't give
the -dirty suffix.
* But if you add an untracked path in its submodule, the command
does give you the -dirty suffix.
A fix, without the first-step to give the command configurable
definition of what makes a repository 'dirty', would probably look
like the attached untested patch. A fix to "diff" machinery to make
"--ignore-submodules=untracked" the default would also make "describe"
internally consistent, too.
builtin/describe.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/describe.c b/builtin/describe.c
index 7668591d57..af08d7d8cf 100644
--- a/builtin/describe.c
+++ b/builtin/describe.c
@@ -45,7 +45,7 @@ static struct commit_names commit_names;
/* diff-index command arguments to check if working tree is dirty. */
static const char *diff_index_args[] = {
- "diff-index", "--quiet", "HEAD", "--", NULL
+ "diff-index", "--quiet", "--ignore-submodules=untracked", "HEAD", "--", NULL
};
struct commit_name {
