Duy Nguyen <pclouds@xxxxxxxxx> writes: >> But even if inum is unreliable, we should be able to use other >> clues, perhaps the same set of fields we use for cached stat >> matching optimization we use for "diff" plumbing commands, to >> implement the error report. The more important part of the idea is >> that we already need to notice that we need to remove a path that is >> in the working tree while doing the checkout, so the alternative >> approach won't incur any extra cost for normal cases where the >> project being checked out does not have two files whose pathnames >> are only different in case (or checking out such an offending >> project to a case sensitive filesytem, of course). >> >> So I guess it still _is_ workable. Any takers? > > 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. Thanks.
