Thread (3 messages) 3 messages, 3 authors, 2016-06-15

Re: Git Bug report

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:52:11

Phil Hord [off-list ref] writes:
On Oct 5, 2011 9:14 PM, "SZEDER Gábor" [off-list ref] wrote:
quoted
On Wed, Oct 05, 2011 at 05:44:54PM -0700, Junio C Hamano wrote:
quoted
SZEDER Gábor [off-list ref] writes:
quoted
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?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help