On Wed, Dec 10, 2014 at 4:47 AM, Jeff King <peff@xxxxxxxx> wrote: > On Wed, Dec 10, 2014 at 03:36:31AM -0500, Eric Sunshine wrote: > >> On Wed, Dec 10, 2014 at 2:34 AM, Jeff King <peff@xxxxxxxx> wrote: >> > Below is a another iteration on the patch. The actual code changes are >> > the same as the strbuf one, but the tests take care to avoid assuming >> > the filesystem can handle such a long path. Testing on Windows and OS X >> > is appreciated. >> >> All three new tests fail on OS X. Thus far brief examination of the >> first failing tests shows that 'expect' and 'actual' differ: >> >> expect: >> long >> master >> >> actual: >> master > > Ugh. It looks like the packed-refs reader uses a PATH_MAX-sized buffer > to read each line, and simply omits the ref. That may be something we > want to work on, but it's a separate topic. I think there are platforms > whose PATH_MAX is much smaller than what they can actually represent. > So ideally we would lift the arbitrary PATH_MAX limitations inside git, > and just let the OS complain when we exceed its limits. > > Even if we fix that, though, I think the push test would still fail on > systems that have a true limit on the filesystem. Writing to a ref > requires taking a lock in the filesystem, which will involve creating > the too-long path. I think there are simply some systems that will not > support long refs well, and the tests need to be skipped there. > > So here's a re-roll that uses prerequisites. On OS X, this version correctly skips the two final tests as intended. -- 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