Re: [PATCH v2 1/4] odb: decouple source path comparisons from `the_repository`

Jeff King <[email protected]> writes:

> How bad is a duplicate alternate? It's a minor performance issue, I'd
> think. We would add its packs to the list (though hardly ever look
> through them, as the "first" copy would satisfy most requests, and the
> unused second copies end up at the back of the MRU list). You'd only pay
> the extra lookup cost for an object which we fail to find entirely,
> which is rare-ish (mostly speculative lookups for fetches).

There may be a future application to be written to go through list
of alternates---enumerate all objects that exist in the first one,
and then remove them as duplicates to other alternates.  Oops, there
was a duplicated entry and we ended up removing the objects from the
first one registered under a different spelling.

Oops (U+1F60F Smirking Face 😏).

> So I kind of wonder if we could just do away with considering case
> insensitivity here at all. We'd err on the side of correctness in the
> ambiguous cases, and this code complexity can just go away.

I like the simplicity.

> Alternatively, I think we could probably make the check more thorough in
> a similar way. Always consider a pair of case-insensitive matches as
> possible duplicates, and then for each possible duplicate use stat() to
> check their st_dev and st_ino values. That keeps things cheap for normal
> cases, and we pay only the stat() before de-duping. It's correct and
> doesn't rely on the repo, though it is a bit more somewhat complicated
> code.

Hmph, I prefer not to trust st_dev and st_ino on platforms where
case insensitivity can possibly become an issue, though.

> [1] Even on a single filesystem I think case-sensitivity check is not
>     completely sufficient either. We know that filesystems do more
>     complicated one-way transformations than just case folding, like
>     unicode normalization or even removing some funky code points.
>     We'd miss those "equivalent" spellings.

macOS?