{"thread":{"id":"37744","subject":"git describe oddity with GIT_DIR","startedAt":"2014-10-16T13:34:29Z","lastAt":"2014-10-16T19:27:45Z","messageCount":3,"participants":["Thomas Braun","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"250752","messageId":"543FC965.7040600@virtuell-zuhause.de","threadId":"37744","inReplyTo":null,"subject":"git describe oddity with GIT_DIR","fromName":"Thomas Braun","fromEmail":"thomas.braun@virtuell-zuhause.de","sentAt":"2014-10-16T13:34:29Z","receivedAt":"2014-10-16T13:34:29Z","isPatch":false,"sender":{"key":"thomas.braun@virtuell-zuhause.de","avatar":"https://avatars.githubusercontent.com/u/1185677?v=4"},"body":"Hi,\n\nI've encountered an oddity with git describe.\nConsider the following snippet:\n-----\nmkdir test\ncd test\ngit init\necho 1 > file\ngit add file\ngit commit -m \"changes\"\n$ git describe --always --dirty\n8ad486e\n$ cd ..\n$ git --git-dir=test/.git describe --always --dirty\n8ad486e-dirty\n$ GIT_DIR=test/.git git describe --always --dirty\n8ad486e-dirty\n-----\n\nThe \"-dirty\" suffix appears if invoking git not from the worktree\nitself, but should actually never appear.\n\nAccording to my research this behaviour is there since 9f67d2e8 (Teach\n\"git describe\" --dirty option, 2009-10-27).\n\nIs that to expected?\n\nThanks\nThomas\n"},{"id":"250757","messageId":"xmqq1tq8uf4f.fsf@gitster.dls.corp.google.com","threadId":"37744","inReplyTo":"543FC965.7040600@virtuell-zuhause.de","subject":"Re: git describe oddity with GIT_DIR","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-10-16T16:57:20Z","receivedAt":"2014-10-16T16:57:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Braun <thomas.braun@virtuell-zuhause.de> writes:\n\n> I've encountered an oddity with git describe.\n> Consider the following snippet:\n> -----\n> mkdir test\n> cd test\n> git init\n> echo 1 > file\n> git add file\n> git commit -m \"changes\"\n> $ git describe --always --dirty\n> 8ad486e\n> $ cd ..\n> $ git --git-dir=test/.git describe --always --dirty\n> 8ad486e-dirty\n> $ GIT_DIR=test/.git git describe --always --dirty\n> 8ad486e-dirty\n> -----\n>\n> The \"-dirty\" suffix appears if invoking git not from the worktree\n> itself, but should actually never appear.\n\nThis is not oddity with describe.  You are using --git-dir incorrectly.\n\nWhen you tell Git where its repository resides with the $GIT_DIR\nenvironment variable or the --git-dir command-line option, unless\nyou tell it where the top-level of your working tree is, you are\ntelling that your current working directory is the top-level of your\nworking tree.\n\nYou are asking \"git describe\" to describe the state of the HEAD\nincluding the dirtyness of the working tree in various ways.  With\nthe first invocation, you do not tell Git where things are and let\nit correctly figure it out, i.e. you are in 'test' directory and\nrelative to where you are, \".git\" is the repository and \".\" is the\ntop of the working tree.  The commit recorded in the \".git/HEAD\",\ni.e. 8ad486e, is used, and its compared with the working tree to\ndetermine dirtiness.  Specifically, the blob object 8ad486e:file is\nthe same as \"./file\" (that is \"test/file\" relative to where you\nstarted with \"mkdir test\" above).\n\nWith the latter two, you are asking the same question but you go one\nlevel up and then tell Git that the repository is \"test/.git\"\n(correct) and the top of the working tree is \".\" (a lie).  Again,\n\"test/.git/HEAD\" records the same commit, but when trying to compare\nthe contents of its tree, e.g. \"file\" at the top-level in the\ncommit, you do not have \"file\" in the working tree.  Git is led to\nbelieve that you removed \"file\", hence your working tree state is\ndirty.\n\nMake it a habit to always specify GIT_WORK_TREE when you use\nGIT_DIR, unless you know you will always start from the top of the\nworking tree.\n"},{"id":"250763","messageId":"54401C31.5090209@virtuell-zuhause.de","threadId":"37744","inReplyTo":"xmqq1tq8uf4f.fsf@gitster.dls.corp.google.com","subject":"Re: git describe oddity with GIT_DIR","fromName":"Thomas Braun","fromEmail":"thomas.braun@virtuell-zuhause.de","sentAt":"2014-10-16T19:27:45Z","receivedAt":"2014-10-16T19:27:45Z","isPatch":false,"sender":{"key":"thomas.braun@virtuell-zuhause.de","avatar":"https://avatars.githubusercontent.com/u/1185677?v=4"},"body":"Am 16.10.2014 um 18:57 schrieb Junio C Hamano:\n> Thomas Braun <thomas.braun@virtuell-zuhause.de> writes:\n> \n>> I've encountered an oddity with git describe.\n>> Consider the following snippet:\n>> -----\n>> mkdir test\n>> cd test\n>> git init\n>> echo 1 > file\n>> git add file\n>> git commit -m \"changes\"\n>> $ git describe --always --dirty\n>> 8ad486e\n>> $ cd ..\n>> $ git --git-dir=test/.git describe --always --dirty\n>> 8ad486e-dirty\n>> $ GIT_DIR=test/.git git describe --always --dirty\n>> 8ad486e-dirty\n>> -----\n>>\n>> The \"-dirty\" suffix appears if invoking git not from the worktree\n>> itself, but should actually never appear.\n> \n> This is not oddity with describe.  You are using --git-dir incorrectly.\n> \n> When you tell Git where its repository resides with the $GIT_DIR\n> environment variable or the --git-dir command-line option, unless\n> you tell it where the top-level of your working tree is, you are\n> telling that your current working directory is the top-level of your\n> working tree.\n> \n> You are asking \"git describe\" to describe the state of the HEAD\n> including the dirtyness of the working tree in various ways.  With\n> the first invocation, you do not tell Git where things are and let\n> it correctly figure it out, i.e. you are in 'test' directory and\n> relative to where you are, \".git\" is the repository and \".\" is the\n> top of the working tree.  The commit recorded in the \".git/HEAD\",\n> i.e. 8ad486e, is used, and its compared with the working tree to\n> determine dirtiness.  Specifically, the blob object 8ad486e:file is\n> the same as \"./file\" (that is \"test/file\" relative to where you\n> started with \"mkdir test\" above).\n> \n> With the latter two, you are asking the same question but you go one\n> level up and then tell Git that the repository is \"test/.git\"\n> (correct) and the top of the working tree is \".\" (a lie).  Again,\n> \"test/.git/HEAD\" records the same commit, but when trying to compare\n> the contents of its tree, e.g. \"file\" at the top-level in the\n> commit, you do not have \"file\" in the working tree.  Git is led to\n> believe that you removed \"file\", hence your working tree state is\n> dirty.\n> \n> Make it a habit to always specify GIT_WORK_TREE when you use\n> GIT_DIR, unless you know you will always start from the top of the\n> working tree.\n\nThanks a lot Junio for the in-depth explanation.\nI'll promise to do more research next time :)\n"}]}