On Thu, Oct 6, 2011 at 12:22 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Phil Hord <phil.hord@xxxxxxxxx> writes: > >> On Oct 5, 2011 9:14 PM, "SZEDER Gábor" <szeder@xxxxxxxxxx> wrote: >>> >>> On Wed, Oct 05, 2011 at 05:44:54PM -0700, Junio C Hamano wrote: >>> > SZEDER Gábor <szeder@xxxxxxxxxx> writes: >>> > >>> > > And what about unreadable .git files? >>> > >>> > Having then inside a working tree is so sick that I do not think it >>> > deserves consideration. >>> >>> I'm not sure why is this any different than having a .git directory >>> that is not a repository inside a working tree. >> >> What should happen here? Ignore it and keep searching? Or fail? >> >> I just added some common gitfile detection code and I noticed that the >> oddball case now is the one that dies on error rather than continuing to >> search for alternate explanations. I left the oddball behavior assuming it >> is desireable, but now you have me rethinking it. > > Yeah, after thinking about it a bit more, whenever we see ".git" during > the upward discovery process, we should always warn if we know it is _not_ > a GIT_DIR before looking for another ".git" at higher levels, as anything > in that directory cannot be added. If we cannot tell if it is or is not > a GIT_DIR, we should error out---the reason we cannot tell most likely is > because we cannot read it, and such a file, if it is not a GIT_DIR, cannot > be tracked in the real GIT_DIR at a higher level, and if it is a GIT_DIR, > we cannot use it to record updates or inspect existing history. > > How's that sound as a guideline? Ok. Three cases, then: if .git is valid, we use it. If .git is bogus, we warn about it and keep searching. If .git is unverifiable (permissions, IO-fail, etc.), we die. Phil -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html