[Bug]: gitcli applies gitfs_root twice when resolving files

What happened

GitFS cannot serve files when gitfs_provider is gitcli and gitfs_root is not empty.

file_list() lists files relative to the configured root. However, find_file() applies gitfs_root twice and looks for a path that does not exist.

Minimal master configuration:

fileserver_backend:
  - git
gitfs_provider: gitcli
gitfs_base: main
gitfs_root: salt
gitfs_remotes:
  - git@example.invalid:owner/states.git

Repository layout:

salt/
  top.sls
  example/
    init.sls

A request for salt://top.sls should resolve to salt/top.sls in the repository. Instead, the GitCLI provider runs the equivalent of:

git ls-tree origin/main salt/salt/top.sls

The lookup then returns no file.

gitfs_mountpoint is empty. Using a per-remote root: salt instead of the global gitfs_root produces the same result.

Steps to reproduce

1. Create a Git repository with salt/top.sls.
2. Configure GitFS as shown above.
3. Run salt-run fileserver.update.
4. Run salt-run fileserver.file_list saltenv=base backend=git and confirm that it lists top.sls.
5. Request salt://top.sls from a minion, or call Fileserver.find_file("top.sls", "base") as the Salt master service user.

The file list succeeds, but the file lookup returns:

{"path": "", "rel": ""}

Tracing GitCLI._run_git() during the lookup shows:

['ls-tree', 'origin/main', 'salt/salt/top.sls']

The repository itself contains the expected path:

$ git ls-tree origin/main salt/top.sls
100644 blob <sha> salt/top.sls

$ git ls-tree origin/main salt/salt/top.sls
<no output>

Expected behaviour

GitCLI should apply gitfs_root once. A request for salt://top.sls should read salt/top.sls from the repository.

The documented global and per-remote forms of gitfs_root should behave consistently across GitFS providers.

Source analysis

The shared GitFS.find_file() adds repo.root(tgt_env) before it calls the provider:

if repo.root(tgt_env):
    repo_path = salt.utils.path.join(repo.root(tgt_env), repo_path)

blob, blob_hexsha, blob_mode = repo.find_file(repo_path, tgt_env)

GitCLI.find_file() then adds the same root again:

tree_path = path
if self.root(tgt_env):
    tree_path = salt.utils.path.join(
        self.root(tgt_env), path, use_posixpath=True
    )

The GitCLI tests set gitfs_root to an empty string. I could not find a test that combines GitCLI.find_file() with a non-empty root.

Installation

• type: official deb, onedir package
• Salt: 3008.2
• operating system: Ubuntu 24.04.4 LTS
• architecture: arm64

salt --versions-report output

Salt Version:
          Salt: 3008.2

Python Version:
        Python: 3.14.6 (main, Jun 11 2026, 02:19:09) [GCC 11.2.0]

Dependency Versions:
          cffi: 2.0.0
      cherrypy: 18.10.0
  cryptography: 48.0.0
      dateutil: 2.9.0.post0
     docker-py: Not Installed
         gitdb: 4.0.12
     gitpython: 3.1.50
        Jinja2: 3.1.6
       libgit2: Not Installed
  looseversion: 1.3.0
      M2Crypto: Not Installed
          Mako: Not Installed
       msgpack: 1.1.2
  msgpack-pure: Not Installed
  mysql-python: Not Installed
     packaging: 24.0
     pycparser: 3.00
      pycrypto: Not Installed
  pycryptodome: 3.23.0
        pygit2: Not Installed
     PyYAML: 6.0.3
         PyZMQ: 27.1.0
        relenv: 0.22.14
         smmap: 5.0.2
       timelib: 0.3.0
       Tornado: 6.5.7
           ZMQ: 4.3.5

Salt Package Information:
  Package Type: onedir

System Versions:
          dist: ubuntu 24.04.4 noble
        locale: utf-8
       machine: aarch64
       release: 6.8.0-1061-raspi
        system: Linux
       version: Ubuntu 24.04.4 noble

Start in salt/utils/gitfs.py at GitFS.find_file() around lines 3921-3976 and GitCLI.find_file() around lines 2847-2864, then inspect the existing GitCLI tests, which use an empty gitfs_root. Reproduce the lookup with a non-empty root and add coverage for the global and per-remote forms. Done means file_list() and find_file() resolve salt://top.sls to salt/top.sls consistently without duplicating the root.