Re: Git Bug report

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 6, 2011, 16:22 UTC
Message-ID: <7vy5wy145q.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CABURp0qCsKG2oOxLw4BfU8UM=9V+pigd69ZK=TZVwetBPqjuiA@mail.gmail.com>

Phil Hord <phil.hord@gmail.com> writes:

Show 19 quoted lines

> On Oct 5, 2011 9:14 PM, "SZEDER Gábor" <szeder@ira.uka.de> wrote:
>>
>> On Wed, Oct 05, 2011 at 05:44:54PM -0700, Junio C Hamano wrote:
>> > SZEDER Gábor <szeder@ira.uka.de> 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?