Closed arkanes closed 7 years ago
alexcrichton
commented
7 years ago Thanks for the report! This is likely coming from libgit2 and is probably a bug in libgit2, but it'd be great if we could work around it. If you've got a reliable reproduction of this it'd be great if you could help out debugging! If we could get a backtrace that'd be invaluable for figuring out what's going wrong here.
arkanes
commented
7 years ago I've traced this back and confirmed that it is a bug in libgit2. It's a loop in git_discover_repository caused by bugs in libgit2s path implementation. It's known and fixed in the latest versions of libgit2:
https://github.com/libgit2/libgit2/issues/4106
I'm not sure if there's any reasonable workaround beyond updating to the latest version of libgit2, short of implementing a manual version of repo scanning.
arkanes
commented
7 years ago Oh, it's worth noting that I'm pretty sure the title of the issue, which says this only happens on directories other than C;\ is just wrong - reviewing the fixes, there's no reason I can see why c:\ is special and bugs reported against other libgit2 language bindings correctly identify it happening in any drive root. Further, the fix itself uses C:\ as its test case.
alexcrichton
commented
7 years ago Oh excellent! I'll go update libgit2 so we can get that bugfix. Thanks so much for investigating!
alexcrichton
commented
7 years ago Ok I've published libgit2-sys 0.6.11 which should have this fix, I've sent a PR to rust-lang/rust to update the lockfile as well.
Executing cargo new directly in a drive root on Windows (eg, C:\ or D:) causes cargo to hang indefinitely at 100% CPU usage. Watching file access using ProcMon shows it attempting to open .git and objects directories, making me think that it's trying to scan upwards for a parent git repo.
Possibly related to #3783?