On Fri, Jan 19, 2018 at 2:40 PM, Eric Sunshine <sunshine@xxxxxxxxxxxxxx> wrote: > On Fri, Jan 19, 2018 at 12:31:58PM +0700, Duy Nguyen wrote: >> On Fri, Jan 19, 2018 at 10:40 AM, brian m. carlson >> > I'm still extremely puzzled as to why this doesn't fail on Linux. If >> > it's failing in this case, it should very, very clearly fail all the >> > time we access an empty blob or an empty tree.[...] >> >> I think it's file system related, case-insensitive one in particular. >> >> The call trace posted at the beginning of this thread should never >> trigger for an initial clone. You only check if an _existing_ entry >> matches what you are about to checkout when you switch trees. For this >> to happen at clone time, I suppose you have to checkout entry "A", >> then re-checkout "A" again. Which can only happen on case-insensitive >> file systems and a case-sensitive repo where the second "A" might >> actually be "a". >> [...] >> On Linux, after I hacked all over the place to force ce_match_stat() >> to eventually call index_fd() which in turns must use one of the >> hashing function, I got a crash. > > Nice detective work. And not stepping back to think for a bit. I realized now that if I just mounted a vfat filesystem, I could have verified it much quicker. It does crash on linux with similar stack trace. (gdb) bt #0 0x000000000055809f in is_empty_blob_sha1 (sha1=0x8fa6d4 "\236") at cache.h:1055 #1 0x0000000000558acd in ce_match_stat_basic (ce=0x8fa690, st=0x7fffffffcd20) at read-cache.c:272 #2 0x0000000000558c78 in ie_match_stat (istate=0x8e9fc0 <the_index>, ce=0x8fa690, st=0x7fffffffcd20, options=5) at read-cache.c:342 #3 0x0000000000501e01 in checkout_entry (ce=0x8fa690, state=0x7fffffffcea0, topath=0x0) at entry.c:424 #4 0x00000000005c8ea0 in check_updates (o=0x7fffffffd060) at unpack-trees.c:383 #5 0x00000000005cb2bb in unpack_trees (len=1, t=0x7fffffffd010, o=0x7fffffffd060) at unpack-trees.c:1382 #6 0x00000000004214ca in checkout (submodule_progress=1) at builtin/clone.c:750 #7 0x00000000004229ce in cmd_clone (argc=1, argv=0x7fffffffd840, prefix=0x0) at builtin/clone.c:1191 #8 0x0000000000405846 in run_builtin (p=0x89a908 <commands+456>, argc=2, argv=0x7fffffffd840) at git.c:346 #9 0x0000000000405af7 in handle_builtin (argc=2, argv=0x7fffffffd840) at git.c:554 #10 0x0000000000405c8f in run_argv (argcp=0x7fffffffd6fc, argv=0x7fffffffd6f0) at git.c:606 #11 0x0000000000405e31 in cmd_main (argc=2, argv=0x7fffffffd840) at git.c:683 #12 0x00000000004a3231 in main (argc=3, argv=0x7fffffffd838) at common-main.c:43 > This particular manifestation is caught by the > following test which fails without brian's patch on MacOS (and > presumably Windows) and succeeds with it. On Linux and BSD, it will of > course succeed always, so I'm not sure how much practical value it > has. There's a travis job running "on windows" (I don't what it really means) so it might help actually. This vim-colorschemes repository has shown up in git mailing list before, I think. We probably should just add it as part of our regression tests ;-) -- Duy
