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? -- 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