git describe oddity with GIT_DIR
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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git describe oddity with GIT_DIR
Thomas Braun thomas.br...@virtuell-zuhause.de 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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git describe oddity with GIT_DIR
Am 16.10.2014 um 18:57 schrieb Junio C Hamano: Thomas Braun thomas.br...@virtuell-zuhause.de 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 :) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
