{"thread":{"id":"12730","subject":"confusing GIT_DIR behavior case","startedAt":"2008-03-17T22:43:49Z","lastAt":"2008-03-17T23:00:54Z","messageCount":2,"participants":["Britton Kerin","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"72322","messageId":"1205793829.5984.1242927563@webmail.messagingengine.com","threadId":"12730","inReplyTo":null,"subject":"confusing GIT_DIR behavior case","fromName":"Britton Kerin","fromEmail":"bkerin@fastmail.fm","sentAt":"2008-03-17T22:43:49Z","receivedAt":"2008-03-17T22:43:49Z","isPatch":false,"sender":{"key":"bkerin@fastmail.fm","avatar":null},"body":"\nI'm noob so wanted to see 'git_repo' instead of invisible '.git'.\nI tried GIT_DIR=git_repo after looking at \n\n       GIT_DIR\n              If the GIT_DIR environment variable is set then it\n              specifies a\n              path to use instead of the default .git for the base of\n              the\n              repository.\n\nin the man page plus the usual mantra of \n \n       git init \n       git add .\n       git commit\n\nin many git noob docs.\n\nBut it fails like this:\n\n       rhino$ mkdir test\n       rhino$ cd test\n       rhino$ export GIT_DIR=git_repo\n       rhino$ git init\n       Initialized empty Git repository in git_repo/\n       rhino$ git add .\n       fatal: This operation must be run in a work tree\n\nI had to irc to hear that git_repo must be added to info/exclude (even\nthough '.git' isnt in there :).\n\nConfusingly I was able to grope up a GIT_WORK_TREE setting (I forget\nexactly\nwhat) that made 'git add .' work but then 'git commit' failed.\n\nIt seems to me that at least one of these options should be useful (I\ndoubt I\nknow enought to know which):\n\n   1.  GIT_DIR (and --git-dir) should make git behave exactly as if git\n   was \n       wired to look for $GIT_DIR rather than '.git'.  The occurence of\n       the\n       GIT_DIR description in the top-level man page (for 'man git')\n       seems to\n       suggest that this is how things work.\n\n   2.  The above man page section should be changed, and --git-dir\n   option\n       description should be expanded a bit, or referred to the section\n       describing GIT_DIR.\n\n   3.  The above diagnostic should be changed.  It looks to me like its\n   running\n       some test to determine that its in the repo directory and then\n       giving\n       up, presumably because it believes it was erroneously invoked\n       there.  The\n       error is the first thing that shows up in the above case probably\n       because\n       the git_repo is the first directory in a recursive traversal\n       where there is\n       a problem.  If this is the case it would be a nice clue if it\n       would spit out\n       the name of the offending directory.\n\n   4.  The noob docs should make some mention of this issue.\n\nCheers,\nBritton\n"},{"id":"72323","messageId":"7v8x0harbt.fsf@gitster.siamese.dyndns.org","threadId":"12730","inReplyTo":"1205793829.5984.1242927563@webmail.messagingengine.com","subject":"Re: confusing GIT_DIR behavior case","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-03-17T23:00:54Z","receivedAt":"2008-03-17T23:00:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Britton Kerin\" <bkerin@fastmail.fm> writes:\n\n>    1.  GIT_DIR (and --git-dir) should make git behave exactly as if git\n>    was \n>        wired to look for $GIT_DIR rather than '.git'.  The occurence of\n>        the\n>        GIT_DIR description in the top-level man page (for 'man git')\n>        seems to\n>        suggest that this is how things work.\n\nThat's underdescribing things.  Presense of GIT_DIR means much more than\nthat (e.g. you are at the top-level of the repository unless you have\nWORK_TREE).\n\n>    4.  The noob docs should make some mention of this issue.\n\nWhich \"noob docs\" did you look at (and do you think other people would\nmost likely to look at)?  I think the most important description they need\nis not to mess with these environment variables.  It might sometimes be\nneeded to move .git away from its default place (and I haven't been in\nthat situation yet, so you have to be more advanced than me ;-)), but if\nyou are doing such a non-default thing, you are certainly no longer\n\"noob\".\n"}]}