# git describe oddity with GIT_DIR 3 messages from 2014-10-16 to 2014-10-16. Participants: Thomas Braun, Junio C Hamano. Thread: https://gitlist.dev/t/37744 ## Thomas Braun, 2014-10-16 13:34 Subject: git describe oddity with GIT_DIR Message-ID: <543FC965.7040600@virtuell-zuhause.de> URL: https://gitlist.dev/e/543FC965.7040600%40virtuell-zuhause.de ``` 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, 2014-10-16 16:57 Subject: Re: git describe oddity with GIT_DIR Message-ID: URL: https://gitlist.dev/e/xmqq1tq8uf4f.fsf%40gitster.dls.corp.google.com In-Reply-To: <543FC965.7040600@virtuell-zuhause.de> ``` Thomas Braun writes: > 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. 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, 2014-10-16 19:27 Subject: Re: git describe oddity with GIT_DIR Message-ID: <54401C31.5090209@virtuell-zuhause.de> URL: https://gitlist.dev/e/54401C31.5090209%40virtuell-zuhause.de In-Reply-To: ``` Am 16.10.2014 um 18:57 schrieb Junio C Hamano: > Thomas Braun writes: > >> 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. > > 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 :) ```