* Jeff King <peff@xxxxxxxx> wrote: > On Tue, Apr 28, 2009 at 11:29:43PM -0400, Jeff King wrote: > > > Note the repeated use of "hopefully". :) Maybe the earlier > > message is too hidden to rely on. We might be able to get by > > with checking "errno" for ENOTDIR after trying to lock the ref > > and using a different message, but I don't know how portable > > that will be. > > Hmm, that actually doesn't work. errno is properly EACCESS in your > example, but the D/F problem doesn't actually set errno, since it > is git itself, and not a failed syscall, that determines that > "foo/bar" is not available because "foo" exists (and git must do > it, because "foo" may be a packed ref). > > So I think we would need to simulate the errno setting, like the > patch below. That should generate the hint only when it would > actually be useful. it wasnt hard to figure out what's going on. So this was more of a FYI, not really a bug report. Maybe if someone tries to pull into a read-only repo the same could happen? My particular breakage (of a single ref being root-owned - the rest was mingo owned) is atypical enough to be ignored. If there's no easy/clean solution then please ignore my report. Ingo -- 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