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

[Jeff King <peff@peff.net>]

On Mon, Aug 17, 2026 at 07:39:05AM +0200, Patrick Steinhardt wrote:

> I also had the feeling that case insensitivity is quite a bit lacking,
> too. What we're really after is whether two directories are actually the
> exact same path. And whether the path is case-insensitive is only one
> part of that equation, so it's an imperfect metric by itself already.
> 
> Ideally, we should probably use realpath(3p) to at least also resolve
> symlinks. Unfortunately, it's not guaranteed that this function also
> knows to canonicalize casing.

Yeah, exactly. I don't think we have a completely robust way of doing
that check.

> > 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.
> 
> You will of course be able to craft edge cases where that would be a
> significant regression. But if your alternates file looks like this you
> may be holding it wrong:
> 
>     /path/to/alternate
>     /PATH/TO/ALTERNATE
>     /pAtH/tO/aLtErNaTe
>     /PaTh/To/AlTeRnAtE

Agreed. The more likely case to me is that repo "A" points to "B" and
"C", then "B" also points to "c" (lowercase). Or you can imagine other
tree structures that converge.

I don't think you could ever get there with standard Git commands,
though. We only ever insert a single alternate via "clone --shared", so
they always form a chain. To get multiple entries I think you'd have to
create the alternates file manually.

  You could also have a chain that forms a loop, but I think you are
  probably beyond screwed at that point anyway. And also probably
  impossible to do with "clone --shared", as the parent repo must
  already exist.

So yeah, I'd be highly surprised if anybody outside of specialized
alternates-tweaking scripts (like the ones that forges use) would ever
construct a situation where duplicates even mattered, let alone their
case. In the case of GitHub's scripts, they were always boring and
one-level anyway (forks point to a shared repo).

IIRC talking to kernel.org folks long ago, they had some kind of tree
structure that matched the filesystem (so foo/bar/baz.git borrowed from
foo/bar.git, which borrowed from foo.git). I don't know if it was a
strict tree, though, or if that system ever even saw production use.

> Hm. Weren't there filesystems where `st_ino` and `st_dev` aren't set at
> all? I think that's the case on Windows, which is unfortunately also the
> one where we see case insensitive filesystems by default. So that makes
> it way less effective, as it only works on systems where we typically
> aren't case-insensitive in the first place (except macOS maybe).
> 
> So if we want to go down this path I'm inclined to just unconditionally
> use case sensitive matching and not introduce any secondary machinery.

Yes, that's my preference, too.

-Peff