On 2018-08-02 15:43, Duy Nguyen wrote: > On Wed, Aug 1, 2018 at 11:20 PM Junio C Hamano <gits...@pobox.com> wrote: >> >> Junio C Hamano <gits...@pobox.com> writes: >> >>> Jeff King <p...@peff.net> 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 would say: Yes. > I can give it another go > (but of course if anybody else steps up, I'd very gladly hand this > over) > Not at the moment.
