git describe oddity with GIT_DIR

[Thomas Braun]

Hi,

I've encountered an oddity with git describe.
Consider the following snippet:
-----
mkdir test
cd test
git init
echo 1 > file
git add file
git commit -m "changes"
$ git describe --always --dirty
8ad486e
$ cd ..
$ git --git-dir=test/.git describe --always --dirty
8ad486e-dirty
$ GIT_DIR=test/.git git describe --always --dirty
8ad486e-dirty
-----

The "-dirty" suffix appears if invoking git not from the worktree
itself, but should actually never appear.

According to my research this behaviour is there since 9f67d2e8 (Teach
"git describe" --dirty option, 2009-10-27).

Is that to expected?

Thanks
Thomas

[Junio C Hamano]

Post by Thomas Braun
I've encountered an oddity with git describe.
-----
mkdir test
cd test
git init
echo 1 > file
git add file
git commit -m "changes"
$ git describe --always --dirty
8ad486e
$ cd ..
$ git --git-dir=test/.git describe --always --dirty
8ad486e-dirty
$ GIT_DIR=test/.git git describe --always --dirty
8ad486e-dirty
-----
The "-dirty" suffix appears if invoking git not from the worktree
itself, but should actually never appear.

This is not oddity with describe. You are using --git-dir incorrectly.

When you tell Git where its repository resides with the $GIT_DIR
environment variable or the --git-dir command-line option, unless
you tell it where the top-level of your working tree is, you are
telling that your current working directory is the top-level of your
working tree.

You are asking "git describe" to describe the state of the HEAD
including the dirtyness of the working tree in various ways. With
the first invocation, you do not tell Git where things are and let
it correctly figure it out, i.e. you are in 'test' directory and
relative to where you are, ".git" is the repository and "." is the
top of the working tree. The commit recorded in the ".git/HEAD",
i.e. 8ad486e, is used, and its compared with the working tree to
determine dirtiness. Specifically, the blob object 8ad486e:file is
the same as "./file" (that is "test/file" relative to where you
started with "mkdir test" above).

With the latter two, you are asking the same question but you go one
level up and then tell Git that the repository is "test/.git"
(correct) and the top of the working tree is "." (a lie). Again,
"test/.git/HEAD" records the same commit, but when trying to compare
the contents of its tree, e.g. "file" at the top-level in the
commit, you do not have "file" in the working tree. Git is led to
believe that you removed "file", hence your working tree state is
dirty.

Make it a habit to always specify GIT_WORK_TREE when you use
GIT_DIR, unless you know you will always start from the top of the
working tree.

[Thomas Braun]

Post by Junio C Hamano

Post by Thomas Braun
I've encountered an oddity with git describe.
-----
mkdir test
cd test
git init
echo 1 > file
git add file
git commit -m "changes"
$ git describe --always --dirty
8ad486e
$ cd ..
$ git --git-dir=test/.git describe --always --dirty
8ad486e-dirty
$ GIT_DIR=test/.git git describe --always --dirty
8ad486e-dirty
-----
The "-dirty" suffix appears if invoking git not from the worktree
itself, but should actually never appear.

This is not oddity with describe. You are using --git-dir incorrectly.
When you tell Git where its repository resides with the $GIT_DIR
environment variable or the --git-dir command-line option, unless
you tell it where the top-level of your working tree is, you are
telling that your current working directory is the top-level of your
working tree.
You are asking "git describe" to describe the state of the HEAD
including the dirtyness of the working tree in various ways. With
the first invocation, you do not tell Git where things are and let
it correctly figure it out, i.e. you are in 'test' directory and
relative to where you are, ".git" is the repository and "." is the
top of the working tree. The commit recorded in the ".git/HEAD",
i.e. 8ad486e, is used, and its compared with the working tree to
determine dirtiness. Specifically, the blob object 8ad486e:file is
the same as "./file" (that is "test/file" relative to where you
started with "mkdir test" above).
With the latter two, you are asking the same question but you go one
level up and then tell Git that the repository is "test/.git"
(correct) and the top of the working tree is "." (a lie). Again,
"test/.git/HEAD" records the same commit, but when trying to compare
the contents of its tree, e.g. "file" at the top-level in the
commit, you do not have "file" in the working tree. Git is led to
believe that you removed "file", hence your working tree state is
dirty.
Make it a habit to always specify GIT_WORK_TREE when you use
GIT_DIR, unless you know you will always start from the top of the
working tree.

Thanks a lot Junio for the in-depth explanation.
I'll promise to do more research next time :)