On Thu, Aug 02, 2018 at 09:27:31AM -0700, Junio C Hamano wrote: > > OK so we're going back to the original way of checking that we check > > out the different files on the same place (because fs is icase) and > > try to collect all paths for reporting, yes? I can give it another go > > (but of course if anybody else steps up, I'd very gladly hand this > > over) > > Detect and report, definitely yes; I am not sure about collect all > (personally I am OK if we stopped at reporting "I tried to check out > X but your project tree has something else that is turned to X by > your pathname-smashing filesystem" without making it a requirement > to report what the other one that conflict with X is. Of course, > reporting the other side _is_ nicer and I'd be happier if we can do > so without too much ugly code, but I do not think it is a hard > requirement. Yeah, I think it would be OK to issue the warning for the conflicted path, and then if we _can_ produce the secondary list of colliding paths, do so. Even on a system with working inodes, we may not come up with a match (e.g., if it wasn't us who wrote the file, but rather we raced with some other process). I also wonder if Windows could return some other file-unique identifier that would work in place of an inode here. That would be pretty easy to swap in via an #ifdef's helper function. I'd be OK shipping without that and letting Windows folks fill it in later (as long as we do not do anything too stupid until then, like claim all of the inode==0 files are the same). -Peff PS It occurs to me that doing this naively (re-scan the entries already checked out when we see a collision) ends up quadratic over the number of entries in the worst case. That may not matter. You'd only have a handful of collisions normally, and anybody malicious can already git-bomb your checkout anyway. If we care, an alternative would be to set a flag for "I saw some collisions", and then follow up with a single pass putting entries into a hashmap of inode->filename.
