> From: Ship Mints <shipmints@gmail.com>
> Date: Mon, 24 Mar 2025 11:15:20 -0400
> Cc: dancol@dancol.org, 77122@debbugs.gnu.org, dmitry@gutov.dev
>
>
> On Mon, Mar 24, 2025 at 9:03 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
>  AFAIR, you didn't respond to my suggest to try a different solution.
>  Namely, instead of changing the file name by resolving links,
>  something that could cause problems for some people, how about using
>  file-equal-p to avoid duplication of projects in these cases?  If my
>  proposal makes sense, it will allow use to avoid duplication without
>  changing the file names, because symlinks will be chased internally,
>  only where we decide whether two projects are different or not.
>
>  This is better than having an optional behavior, because inevitably
>  someone will want to use this option, but also wouldn't like his/her
>  project directories appear under their resolved names, and then we are
>  back at the same problem.
>
> I did consider it.  The most popular project objects, project-vc, and transient are defined as (list 'vc
> vcbackend dir) and (cons 'transient dir), respectively and vc objects are cached.  If we don't canonicalize the
> dir name, we can't find the vc cache entry if a probe is attempted from another dir, even if that dir morally is
> equivalent.

Why can't we? what precludes that?

> If you see the place in project.el where file-equal-p helps, I'll happily hack on it.

I'm sorry, I cannot afford looking through the project.el code to find
this.  But if the problem is that directories or files don't compare
equal, the file-equal-p is the way to go, so I don't understand why
the places where we do the comparison should be hard to find for
someone who knows their way in project.el's code and/or has enough
time to dig.