Subject: Re: Update symlinks after changing core.symlinks

From: "brian m. carlson" <[email-masked]>
Date: Thu, 3 Apr 2025 22:25:57 +0000

On 2025-04-02 at 22:41:50, brian m. carlson wrote:
> On 2025-04-02 at 07:18:45, Andrej Zhilenkov wrote:
> > Hello! Is there a direct way to update symlinks in repo after changing
> > core.symlinks?
> > E.g. update plain files, if it was false, with symlinks or vice versa.
> > 
> > I've tried `checkout` and `reset` but they have no effect in this case
> > (see the snippet below). The only two things that are working:
> > - checking out a commit before the symlink was introduced and then
> > checking out any commit after (need to know that special commit to
> > make it work for those specific symlinks, not practical)
> > - removing symlinked files and checking them out specifically (need to
> > either have a list or somehow search for those files to reset)
> > 
> > Is this the way to do it or is there an alternative?
> 
> We don't have a way to do this because `core.symlinks` is intended as a
> hint from Git to itself about whether the file system and operating
> system support symlinks that's determined when the repository is
> created.  It's not intended that users modify it, much like
> `core.filemode` or `core.ignorecase`.
> 
> What is your particular use case that requires changing this value?

I'll also just mention that this seems to be a particular variant of a
use case I've seen elsewhere, which is to force Git to re-check out
every object (or at least re-evaluate which objects need to be checked
out).

Notably, in Git LFS, it's possible to have the small pointer files in
the tree or the large objects.  Going from the former to the latter can
be done with `git lfs checkout`, but there isn't a good way to go back
from the latter to the former.  `git checkout` and `git read-tree` don't
seem to work properly.  I think blowing the index away is possible, but
that's obviously less good for lots of reasons.  A simple re-evaluation
of the smudge filter on each filtered object during a commit would work,
though.

So if there's a good use case for the symlink change, such a feature
might be more generally useful.  I don't plan to implement such a
feature, but I would welcome such a change.  I am still curious about
the reason for changing `core.symlinks`, though.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA