On Wed, Aug 1, 2018 at 11:20 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Junio C Hamano <gitster@xxxxxxxxx> writes: > > > Jeff King <peff@xxxxxxxx> writes: > > > >>> Presumably we are already in an error codepath, so if it is > >>> absolutely necessary, then we can issue a lstat() to grab the inum > >>> for the path we are about to create, iterate over the previously > >>> checked out paths issuing lstat() and see which one yields the same > >>> inum, to find the one who is the culprit. > >> > >> Yes, this is the cleverness I was missing in my earlier response. > >> > >> So it seems do-able, and I like that this incurs no cost in the > >> non-error case. > > > > Not so fast, unfortunately. > > > > I suspect that some filesystems do not give us inum that we can use > > for that "identity" purpose, and they tend to be the ones with the > > case smashing characteristics where we need this code in the error > > path the most X-<. > > 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) -- Duy
