Re: Update symlinks after changing core.symlinks

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Apr 3, 2025, 22:25 UTC
Message-ID: <Z-8K9ZIt4j_UMNZm@tapette.crustytoothpaste.net>
In-Reply-To: <Z-29LsgDvcS0qY5a@tapette.crustytoothpaste.net>

On 2025-04-02 at 22:41:50, brian m. carlson wrote:

Show 22 quoted lines

> 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