{"thread":{"id":"28577","subject":"Git Bug report","startedAt":"2011-10-04T21:24:03Z","lastAt":"2011-10-06T22:57:40Z","messageCount":15,"participants":["Federico Lucifredi","Johannes Sixt","Fredrik Gustafsson","Nguyễn Thái Ngọc Duy","Junio C Hamano","Nguyen Thai Ngoc Duy","SZEDER Gábor","Matthieu Moy","Phil Hord","Aaron Schrab"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"176881","messageId":"1317763443.17036.15.camel@skyplex","threadId":"28577","inReplyTo":null,"subject":"Git Bug report","fromName":"Federico Lucifredi","fromEmail":"federico@canonical.com","sentAt":"2011-10-04T21:24:03Z","receivedAt":"2011-10-04T21:24:03Z","isPatch":false,"sender":{"key":"federico@canonical.com","avatar":null},"body":"Hello Git list,\n Found a minor bug in git today - the error message reported is not\ncorrect when trying to access a repo that is not accessible\npermission-wise:\n\n> federico@skyplex:/etc$ git log\n> fatal: Not a git repository (or any of the parent directories): .git\n\nwith correct access permissions, everything works as expected.\n\n> federico@skyplex:/etc$ sudo git log\n> commit 10a1d0eefcc100a513a9dff46839cff2c4f9b5a0\n> Author: root <root@skyplex>\n> Date:   Mon Oct 3 16:53:33 2011 -0400\n>\n>    saving uncommitted changes in /etc prior to apt run\n>\n> commit 2abb2b397631c7f48757bbcb029ebc38e37659d6\n> Author: federico <federico@skyplex>\n> Date:   Mon Oct 3 16:50:16 2011 -0400\n>\n>    updating firefox packages next\n>federico@skyplex:/etc$ \n\n> drwx------   8 root root      4096 2011-10-03 16:53 .git\n\nThat's it... I am not subscribed to the list, CC me in reply as needed.\n\nBest -Federico\n\n-- \n\n_________________________________________\n-- \"'Problem' is a bleak word for challenge\" - Richard Fish\n(Federico L. Lucifredi) - federico at canonical.com - GnuPG 0x4A73884C\n"},{"id":"176902","messageId":"4E8BF519.8090509@viscovery.net","threadId":"28577","inReplyTo":"1317763443.17036.15.camel@skyplex","subject":"Re: Git Bug report","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2011-10-05T06:11:37Z","receivedAt":"2011-10-05T06:11:37Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 10/4/2011 23:24, schrieb Federico Lucifredi:\n> Hello Git list,\n>  Found a minor bug in git today - the error message reported is not\n> correct when trying to access a repo that is not accessible\n> permission-wise:\n> \n>> federico@skyplex:/etc$ git log\n>> fatal: Not a git repository (or any of the parent directories): .git\n> \n> with correct access permissions, everything works as expected.\n\nAnd the correct error message is...?\n\n>> drwx------   8 root root      4096 2011-10-03 16:53 .git\n\nAssuming that you expected something like this:\n\nfatal: .git: permission denied\n\nit is hard to argue that a directory that happens to be named .git, but\nwas sealed by its owner should be assumed to be a git repository, albeit\none that we do not have access to. \"Not a git repository\" is an equally\njustifyable error message, IMHO.\n\n-- Hannes\n"},{"id":"176910","messageId":"20111005072235.GA12600@kolya","threadId":"28577","inReplyTo":"1317763443.17036.15.camel@skyplex","subject":"Re: Git Bug report","fromName":"Fredrik Gustafsson","fromEmail":"iveqy@iveqy.com","sentAt":"2011-10-05T07:22:35Z","receivedAt":"2011-10-05T07:22:35Z","isPatch":false,"sender":{"key":"iveqy@iveqy.com","avatar":"https://avatars.githubusercontent.com/u/761743?v=4"},"body":"On Tue, Oct 04, 2011 at 05:24:03PM -0400, Federico Lucifredi wrote:\n>  Found a minor bug in git today - the error message reported is not\n> correct when trying to access a repo that is not accessible\n> permission-wise:\n> \n> > federico@skyplex:/etc$ git log\n> > fatal: Not a git repository (or any of the parent directories): .git\n> \n> with correct access permissions, everything works as expected.\n\nSo if:\n.git/ is a directory with not enought permissions.\n../.git/ is a directory with enought permissions.\n\ngit would today use ../.git. You suggest that git instead would die\nbecause a .git/ exists? (I'm not saying this is wrong or right).\n\n-- \nMed vänliga hälsningar\nFredrik Gustafsson\n\nE-post: iveqy@iveqy.com\nTel. nr.: 0733 60 82 74\n"},{"id":"176912","messageId":"1317802651-28956-1-git-send-email-pclouds@gmail.com","threadId":"28577","inReplyTo":"4E8BF519.8090509@viscovery.net","subject":"[PATCH] Report errors related to .git access during repository discovery","fromName":"Nguyễn Thái Ngọc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-10-05T08:17:31Z","receivedAt":"2011-10-05T08:17:31Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"If $GIT_DIR is not given, we go up step by step and look for potential\nrepository directory, may see .git directory but for some reasons we\ndecide to skip and move on.\n\nIt's probably better to report along the line, so users can stop\nwondering \"hey, but I have .git directory _there_\".\n\nSigned-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>\n---\n On Wed, Oct 5, 2011 at 5:11 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:\n > Am 10/4/2011 23:24, schrieb Federico Lucifredi:\n >> Hello Git list,\n >>  Found a minor bug in git today - the error message reported is not\n >> correct when trying to access a repo that is not accessible\n >> permission-wise:\n >>\n >>> federico@skyplex:/etc$ git log\n >>> fatal: Not a git repository (or any of the parent directories): .git\n >>\n >> with correct access permissions, everything works as expected.\n >\n > And the correct error message is...?\n\n That's a correct message. But it'd be even better if we help diagnose\n why. Even when you have proper access to .git dir, git can still\n refuse to accept the directory as a repository, because \"HEAD\" is\n invalid for example.\n\n I think a patch like this is an improvement. There may be many\n situations git refuses a directory but I don't cover here. Well, we\n may when users report them\n\n setup.c |   23 +++++++++++++++++++----\n 1 files changed, 19 insertions(+), 4 deletions(-)\n\ndiff --git a/setup.c b/setup.c\nindex 27c1d47..b6028e5 100644\n--- a/setup.c\n+++ b/setup.c\n@@ -269,6 +269,19 @@ const char *pathspec_prefix(const char *prefix, const char **pathspec)\n }\n \n /*\n+ * This function is used during .git detection phase. If .git does not\n+ * exist, it's OK not to report because that happens a lot if you stay\n+ * inside a subdirectory and git checks every level back to topdir.\n+ */\n+static int access_and_warn(const char *path, int perm)\n+{\n+\tint ret = access(path, perm);\n+\tif (ret && errno != ENOENT)\n+\t\terror(\"%s: %s\", absolute_path(path), strerror(errno));\n+\treturn ret;\n+}\n+\n+/*\n  * Test if it looks like we're at a git directory.\n  * We want to see:\n  *\n@@ -288,22 +301,24 @@ static int is_git_directory(const char *suspect)\n \t\tdie(\"Too long path: %.*s\", 60, suspect);\n \tstrcpy(path, suspect);\n \tif (getenv(DB_ENVIRONMENT)) {\n-\t\tif (access(getenv(DB_ENVIRONMENT), X_OK))\n+\t\tif (access_and_warn(getenv(DB_ENVIRONMENT), X_OK))\n \t\t\treturn 0;\n \t}\n \telse {\n \t\tstrcpy(path + len, \"/objects\");\n-\t\tif (access(path, X_OK))\n+\t\tif (access_and_warn(path, X_OK))\n \t\t\treturn 0;\n \t}\n \n \tstrcpy(path + len, \"/refs\");\n-\tif (access(path, X_OK))\n+\tif (access_and_warn(path, X_OK))\n \t\treturn 0;\n \n \tstrcpy(path + len, \"/HEAD\");\n-\tif (validate_headref(path))\n+\tif (validate_headref(path)) {\n+\t\terror(\"invalid HEAD at %s\", absolute_path(path));\n \t\treturn 0;\n+\t}\n \n \treturn 1;\n }\n-- \n1.7.3.1.256.g2539c.dirty\n"},{"id":"176937","messageId":"7vlisz8jur.fsf@alter.siamese.dyndns.org","threadId":"28577","inReplyTo":"20111005072235.GA12600@kolya","subject":"Re: Git Bug report","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-10-05T16:49:00Z","receivedAt":"2011-10-05T16:49:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Fredrik Gustafsson <iveqy@iveqy.com> writes:\n\n> On Tue, Oct 04, 2011 at 05:24:03PM -0400, Federico Lucifredi wrote:\n>>  Found a minor bug in git today - the error message reported is not\n>> correct when trying to access a repo that is not accessible\n>> permission-wise:\n>> \n>> > federico@skyplex:/etc$ git log\n>> > fatal: Not a git repository (or any of the parent directories): .git\n>> \n>> with correct access permissions, everything works as expected.\n>\n> So if:\n> .git/ is a directory with not enought permissions.\n> ../.git/ is a directory with enought permissions.\n>\n> git would today use ../.git. You suggest that git instead would die\n> because a .git/ exists? (I'm not saying this is wrong or right).\n\nFor that matter, if you have .git/ that is a directory but is not a\nrepository, and ../.git/ that is, the same situation would arise. I do not\nthink we should die because .git/ is not a git repository. I do not know\nif we should even warn about it.\n"},{"id":"176950","messageId":"1317839560.20904.20.camel@skyplex","threadId":"28577","inReplyTo":"4E8BF519.8090509@viscovery.net","subject":"Re: Git Bug report","fromName":"Federico Lucifredi","fromEmail":"federico@canonical.com","sentAt":"2011-10-05T18:32:40Z","receivedAt":"2011-10-05T18:32:40Z","isPatch":false,"sender":{"key":"federico@canonical.com","avatar":null},"body":"On Wed, 2011-10-05 at 08:11 +0200, Johannes Sixt wrote:\n> >> federico@skyplex:/etc$ git log\n> >> fatal: Not a git repository (or any of the parent directories): .git\n> > \n> > with correct access permissions, everything works as expected.\n> \n> And the correct error message is...?\n\n\".git: permission denied\" -- no need to be fatal (there could\nbe ../.git, etc - fatal comes only if those don't exist). \n\nIt could fail silently if one of the parents exists, but in the fatal\nscenario, I should be told that it was by permission denied. Currently,\nI am told there is no git repo where I know there to be one, which means\n\"what happened to my repo\" is the next question in the user's head.\n\"it's there but it is broke\" is the subtext one gets from this error. it\nshould be \"it is there, I cannot get to it\".\n\n> >> drwx------   8 root root      4096 2011-10-03 16:53 .git\n> \n> Assuming that you expected something like this:\n> \n> fatal: .git: permission denied\n> \n> it is hard to argue that a directory that happens to be named .git, but\n> was sealed by its owner should be assumed to be a git repository, albeit\n> one that we do not have access to. \"Not a git repository\" is an equally\n> justifyable error message, IMHO.\n\nAn error message should help resolve the error in question, not grade\nthe user's smarts. Here I as a user had an expectation that there was a\ngit repository for /etc (\"I set up one!\") and figured the permission\nissue with my own wits (well, I did not need to because it was /etc, but\nin the general perm-denied case I would have had to), by looking at the\ndir because the message gave me no useful information on the cause of\nthe problem.\n\nThanks -Federico\n-- \n\n_________________________________________\n-- \"'Problem' is a bleak word for challenge\" - Richard Fish\n(Federico L. Lucifredi) - federico at canonical.com - GnuPG 0x4A73884C\n"},{"id":"176969","messageId":"CACsJy8CZT7=b69mPyLPuggH3QPH5cQfbJXD0PWZopKQ03D6MXQ@mail.gmail.com","threadId":"28577","inReplyTo":"7vlisz8jur.fsf@alter.siamese.dyndns.org","subject":"Re: Git Bug report","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-10-05T21:56:40Z","receivedAt":"2011-10-05T21:56:40Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, Oct 6, 2011 at 3:49 AM, Junio C Hamano <gitster@pobox.com> wrote:\n>> So if:\n>> .git/ is a directory with not enough permissions.\n>> ../.git/ is a directory with enough permissions.\n>>\n>> git would today use ../.git. You suggest that git instead would die\n>> because a .git/ exists? (I'm not saying this is wrong or right).\n>\n> For that matter, if you have .git/ that is a directory but is not a\n> repository, and ../.git/ that is, the same situation would arise. I do not\n> think we should die because .git/ is not a git repository. I do not know\n> if we should even warn about it.\n\nProbably not. On the other hand we should show user how we ignored\n.git if we find no good repository in the end. So maybe it's a good\nidea to queue up warnings and only print before git calls die(\"Not a\nrepository\").\n-- \nDuy\n"},{"id":"176982","messageId":"20111006003318.GA9015@goldbirke","threadId":"28577","inReplyTo":"7vlisz8jur.fsf@alter.siamese.dyndns.org","subject":"Re: Git Bug report","fromName":"SZEDER Gábor","fromEmail":"szeder@ira.uka.de","sentAt":"2011-10-06T00:33:18Z","receivedAt":"2011-10-06T00:33:18Z","isPatch":false,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Wed, Oct 05, 2011 at 09:49:00AM -0700, Junio C Hamano wrote:\n> Fredrik Gustafsson <iveqy@iveqy.com> writes:\n> \n> > On Tue, Oct 04, 2011 at 05:24:03PM -0400, Federico Lucifredi wrote:\n> >>  Found a minor bug in git today - the error message reported is not\n> >> correct when trying to access a repo that is not accessible\n> >> permission-wise:\n> >> \n> >> > federico@skyplex:/etc$ git log\n> >> > fatal: Not a git repository (or any of the parent directories): .git\n> >> \n> >> with correct access permissions, everything works as expected.\n> >\n> > So if:\n> > .git/ is a directory with not enought permissions.\n> > ../.git/ is a directory with enought permissions.\n> >\n> > git would today use ../.git. You suggest that git instead would die\n> > because a .git/ exists? (I'm not saying this is wrong or right).\n> \n> For that matter, if you have .git/ that is a directory but is not a\n> repository, and ../.git/ that is, the same situation would arise. I do not\n> think we should die because .git/ is not a git repository. I do not know\n> if we should even warn about it.\n\nAnd what about unreadable .git files?\n\n~/tmp/git/outside$ git init\nInitialized empty Git repository in /home/szeder/tmp/git/outside/.git/\n~/tmp/git/outside$ mkdir inside repo\n~/tmp/git/outside$ cd inside/\n~/tmp/git/outside/inside$ git init --separate-git-dir=../repo\nInitialized empty Git repository in /home/szeder/tmp/git/outside/repo/\n~/tmp/git/outside/inside$ git rev-parse --git-dir\n/home/szeder/tmp/git/outside/repo\n~/tmp/git/outside/inside$ chmod a-r .git\n~/tmp/git/outside/inside$ git rev-parse --git-dir\nfatal: Error opening '.git': Permission denied\n\nOr a non-gitfile .git file?\n\n~/tmp/git/outside/inside$ chmod a+r .git\n~/tmp/git/outside/inside$ echo foo >.git\n~/tmp/git/outside/inside$ git rev-parse --git-dir\nfatal: Invalid gitfile format: .git\n\nShouldn't these also be ignored?\n\n\nBest,\nGábor\n"},{"id":"176985","messageId":"7vobxv3q49.fsf@alter.siamese.dyndns.org","threadId":"28577","inReplyTo":"20111006003318.GA9015@goldbirke","subject":"Re: Git Bug report","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-10-06T00:44:54Z","receivedAt":"2011-10-06T00:44:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"SZEDER Gábor <szeder@ira.uka.de> writes:\n\n> And what about unreadable .git files?\n\nHaving then inside a working tree is so sick that I do not think it\ndeserves consideration.\n\nPlease don't troll immediately after a big release.\n"},{"id":"176989","messageId":"20111006010940.GR2208@goldbirke","threadId":"28577","inReplyTo":"7vobxv3q49.fsf@alter.siamese.dyndns.org","subject":"Re: Git Bug report","fromName":"SZEDER Gábor","fromEmail":"szeder@ira.uka.de","sentAt":"2011-10-06T01:09:40Z","receivedAt":"2011-10-06T01:09:40Z","isPatch":false,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Wed, Oct 05, 2011 at 05:44:54PM -0700, Junio C Hamano wrote:\n> SZEDER Gábor <szeder@ira.uka.de> writes:\n> \n> > And what about unreadable .git files?\n> \n> Having then inside a working tree is so sick that I do not think it\n> deserves consideration.\n\nI'm not sure why is this any different than having a .git directory\nthat is not a repository inside a working tree.\n\n> Please don't troll immediately after a big release.\n\nI didn't mean to troll; it just happened that I came across this issue\nthis weekend while trying to optimize the bash completion code...\n"},{"id":"177044","messageId":"7vy5wy145q.fsf@alter.siamese.dyndns.org","threadId":"28577","inReplyTo":"CABURp0qCsKG2oOxLw4BfU8UM=9V+pigd69ZK=TZVwetBPqjuiA@mail.gmail.com","subject":"Re: Git Bug report","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-10-06T16:22:09Z","receivedAt":"2011-10-06T16:22:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Phil Hord <phil.hord@gmail.com> writes:\n\n> On Oct 5, 2011 9:14 PM, \"SZEDER Gábor\" <szeder@ira.uka.de> wrote:\n>>\n>> On Wed, Oct 05, 2011 at 05:44:54PM -0700, Junio C Hamano wrote:\n>> > SZEDER Gábor <szeder@ira.uka.de> writes:\n>> >\n>> > > And what about unreadable .git files?\n>> >\n>> > Having then inside a working tree is so sick that I do not think it\n>> > deserves consideration.\n>>\n>> I'm not sure why is this any different than having a .git directory\n>> that is not a repository inside a working tree.\n>\n> What should happen here? Ignore it and keep searching? Or fail?\n>\n> I just added some common gitfile detection code and I noticed that the\n> oddball case now is the one that dies on error rather than continuing to\n> search for alternate explanations.  I left the oddball behavior assuming it\n> is desireable, but now you have me rethinking it.\n\nYeah, after thinking about it a bit more, whenever we see \".git\" during\nthe upward discovery process, we should always warn if we know it is _not_\na GIT_DIR before looking for another \".git\" at higher levels, as anything\nin that directory cannot be added. If we cannot tell if it is or is not\na GIT_DIR, we should error out---the reason we cannot tell most likely is\nbecause we cannot read it, and such a file, if it is not a GIT_DIR, cannot\nbe tracked in the real GIT_DIR at a higher level, and if it is a GIT_DIR,\nwe cannot use it to record updates or inspect existing history.\n\nHow's that sound as a guideline?\n"},{"id":"177046","messageId":"vpq1uuq13yz.fsf@bauges.imag.fr","threadId":"28577","inReplyTo":"7vy5wy145q.fsf@alter.siamese.dyndns.org","subject":"Re: Git Bug report","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2011-10-06T16:26:12Z","receivedAt":"2011-10-06T16:26:12Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n>  If we cannot tell if it is or is not\n> a GIT_DIR, we should error out---the reason we cannot tell most likely is\n> because we cannot read it, and such a file, if it is not a GIT_DIR, cannot\n> be tracked in the real GIT_DIR at a higher level, and if it is a GIT_DIR,\n> we cannot use it to record updates or inspect existing history.\n\nPlus, the user may have removed the permission on the .git directory by\nmistake, and it would be very surprising behavior if git ran without\ncomplaining using a higher level GIT_DIR (i.e. a more or less arbitrary\nrepo as far as the user is concerned ...)\n\n> How's that sound as a guideline?\n\nSounds reasonable, yes.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"177048","messageId":"CABURp0qw55bKNEjAnn5UHc5nPqiF4MEyG4SmHZf3qJEDFaug2g@mail.gmail.com","threadId":"28577","inReplyTo":"20111006010940.GR2208@goldbirke","subject":"Re: Git Bug report","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2011-10-06T16:48:14Z","receivedAt":"2011-10-06T16:48:14Z","isPatch":false,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On 10/5/11, SZEDER Gábor <szeder@ira.uka.de> wrote:\n> On Wed, Oct 05, 2011 at 05:44:54PM -0700, Junio C Hamano wrote:\n>> SZEDER Gábor <szeder@ira.uka.de> writes:\n>>\n>> > And what about unreadable .git files?\n>>\n>> Having then inside a working tree is so sick that I do not think it\n>> deserves consideration.\n>\n> I'm not sure why is this any different than having a .git directory\n> that is not a repository inside a working tree.\n\nWhat should happen here? Ignore it and keep searching? Or fail?\n\nI just added some common gitfile detection code and I noticed that the\noddball case now is the one that dies on error rather than continuing\nto search for alternate explanations. I left the oddball behavior\nassuming it is desireable, but now you have me rethinking it.\n\nPhil\n"},{"id":"177054","messageId":"CABURp0pGatN=i2V8sycD=w7EedYxMFHbw6JZNVaQV0vYRG8Hww@mail.gmail.com","threadId":"28577","inReplyTo":"7vy5wy145q.fsf@alter.siamese.dyndns.org","subject":"Re: Git Bug report","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2011-10-06T16:54:14Z","receivedAt":"2011-10-06T16:54:14Z","isPatch":false,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On Thu, Oct 6, 2011 at 12:22 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Phil Hord <phil.hord@gmail.com> writes:\n>\n>> On Oct 5, 2011 9:14 PM, \"SZEDER Gábor\" <szeder@ira.uka.de> wrote:\n>>>\n>>> On Wed, Oct 05, 2011 at 05:44:54PM -0700, Junio C Hamano wrote:\n>>> > SZEDER Gábor <szeder@ira.uka.de> writes:\n>>> >\n>>> > > And what about unreadable .git files?\n>>> >\n>>> > Having then inside a working tree is so sick that I do not think it\n>>> > deserves consideration.\n>>>\n>>> I'm not sure why is this any different than having a .git directory\n>>> that is not a repository inside a working tree.\n>>\n>> What should happen here? Ignore it and keep searching? Or fail?\n>>\n>> I just added some common gitfile detection code and I noticed that the\n>> oddball case now is the one that dies on error rather than continuing to\n>> search for alternate explanations.  I left the oddball behavior assuming it\n>> is desireable, but now you have me rethinking it.\n>\n> Yeah, after thinking about it a bit more, whenever we see \".git\" during\n> the upward discovery process, we should always warn if we know it is _not_\n> a GIT_DIR before looking for another \".git\" at higher levels, as anything\n> in that directory cannot be added. If we cannot tell if it is or is not\n> a GIT_DIR, we should error out---the reason we cannot tell most likely is\n> because we cannot read it, and such a file, if it is not a GIT_DIR, cannot\n> be tracked in the real GIT_DIR at a higher level, and if it is a GIT_DIR,\n> we cannot use it to record updates or inspect existing history.\n>\n> How's that sound as a guideline?\n\nOk.  Three cases, then:\n\nif .git is valid, we use it.\nIf .git is bogus, we warn about it and keep searching.\nIf .git is unverifiable (permissions, IO-fail, etc.), we die.\n\nPhil\n"},{"id":"177123","messageId":"20111006225740.GG24640@pug.qqx.org","threadId":"28577","inReplyTo":"7vy5wy145q.fsf@alter.siamese.dyndns.org","subject":"Re: Git Bug report","fromName":"Aaron Schrab","fromEmail":"aaron@schrab.com","sentAt":"2011-10-06T22:57:40Z","receivedAt":"2011-10-06T22:57:40Z","isPatch":false,"sender":{"key":"aaron@schrab.com","avatar":"https://avatars.githubusercontent.com/u/39620?v=4"},"body":"At 09:22 -0700 06 Oct 2011, Junio C Hamano <gitster@pobox.com> wrote:\n>Yeah, after thinking about it a bit more, whenever we see \".git\" during\n>the upward discovery process, we should always warn if we know it is _not_\n>a GIT_DIR before looking for another \".git\" at higher levels, as anything\n>in that directory cannot be added. If we cannot tell if it is or is not\n>a GIT_DIR, we should error out---the reason we cannot tell most likely is\n>because we cannot read it, and such a file, if it is not a GIT_DIR, cannot\n>be tracked in the real GIT_DIR at a higher level, and if it is a GIT_DIR,\n>we cannot use it to record updates or inspect existing history.\n\nYes, I think that sounds like a good idea.  That should also solve a \nrelated problem that I noticed while checking out the current behaviour.\n\nCurrently if the .git directory of a submodule is inaccessible running \n`git status` from anywhere in the parent repository (including within \nthe submodule) will cause git to recursively call itself until enough \nresources are used to prevent further forking.  I then tried this with \nthe patch from earlier in the thread applied, but with the call to \nerror() changed to call die() instead.  With that change it quickly \nfailed with a useful error message.\n"}]}