worktree remove: use gvfs_config_is_set for skip-clean-check gate

[tyrielv]

The skip-clean-check guard in remove_worktree() was gated on core_virtualfilesystem, which is only initialized by repo_config_get_virtualfilesystem() during index loading. Since the worktree remove path never loads the index before this check, the variable was always NULL, causing check_clean_worktree() to run even when VFSForGit had already unmounted the projection and written the skip-clean-check marker file. This made 'git worktree remove' fail with 'fatal: failed to run git status' in GVFS repos.

Replace core_virtualfilesystem with gvfs_config_is_set(GVFS_USE_VIRTUAL_FILESYSTEM), which is already loaded from core.gvfs by cmd_worktree() before dispatch to remove_worktree().

[dscho]

Good rationale.

A request going forward: Could you add an Assisted-by: Claude Opus 4.6 and your Signed-off-by: trailer, and drop that Co-authored-by: <bogus-email> trailer in your commit messages, please?

Also: I wonder whether any other bare core_virtualfilesystems need the same treatment?

[dscho]

Also: I wonder whether any other bare core_virtualfilesystems need the same treatment?

I guess that the core_virtualfilesystem variable needs to go, actually, and be replaced by accessing gvfs_config_is_set(the_repository, GVFS_USE_VIRTUAL_FILESYSTEM) always, right?

[tyrielv]

Good rationale.

A request going forward: Could you add an Assisted-by: Claude Opus 4.6 and your Signed-off-by: trailer, and drop that Co-authored-by: <bogus-email> trailer in your commit messages, please?

Acknowledged

Also: I wonder whether any other bare core_virtualfilesystems need the same treatment?

I guess that the core_virtualfilesystem variable needs to go, actually, and be replaced by accessing gvfs_config_is_set(the_repository, GVFS_USE_VIRTUAL_FILESYSTEM) always, right?

Anywhere it's used as a flag, it probably should be changed (since I think we've long given up on making the contributions generic enough that a different virtual filesystem could be used than VFSForGit). The content of core_virtualfilesystem is a hook to call to get the list of modified files tracked by the vfs, so when it's used as that hook it would stay as-is.

I'll work on that.

[tyrielv]

Also: I wonder whether any other bare core_virtualfilesystems need the same treatment?

I guess that the core_virtualfilesystem variable needs to go, actually, and be replaced by accessing gvfs_config_is_set(the_repository, GVFS_USE_VIRTUAL_FILESYSTEM) always, right?

Anywhere it's used as a flag, it probably should be changed (since I think we've long given up on making the contributions generic enough that a different virtual filesystem could be used than VFSForGit). The content of core_virtualfilesystem is a hook to call to get the list of modified files tracked by the vfs, so when it's used as that hook it would stay as-is.

I'll work on that.

Every other place core_virtualfilesystem is used as a guard it's related to working with a git index. core_virtualfilesystem is deliberately cleared even if it was configured if the index isn't from the on-disk .git/index file, so it makes sense to use it as a guard in those cases. Also, core_virtualfilesystem is initialized when reading an index, so it's always initialized in the other cases.

This location should definitely use gvfs_config_is_set - but now I think it should use the new GVFS_SUPPORT_WORKTREES bit instead of GVFS_USE_VIRTUAL_FILESYSTEM to be clearer.

[mjcheetham]

Given the use of core_virtualfilesystem in every other place in the codebase, and the issue this caused here, maybe it's worth just a small comment in the code about why we're calling gvfs_config_is_set instead. Future readers may wonder why not just use core_virtualfileystem.

Approving to not block.