[BUG] Unable to use commit hash in ext_pillar

Description

I am able to use a commit hash as the branch name for gitfs_remotes, but not for ext_pillar.

Setup

This was observed when using a masterless salt-minion, running Debian Stable with Salt v3004.

Steps to Reproduce the behavior

This was caused by the following salt template, which generates /etc/salt/minion.d/saltsolo.conf:

file_client: local
top_file_merging_strategy: same
fileserver_backend:
  - gitfs
gitfs_saltenv_whitelist: [base]
gitfs_remotes:
  - https://github.com/foo/bar.git:
    - root: {{ salt.grains.get('bootstrap:states_root', 'states') }}
    - base: {{ salt.grains.get('bootstrap:gitfs_base', 'cicd-release') }}
ext_pillar:
  - git:
    - {{ salt.grains.get('bootstrap:gitfs_base', 'cicd-release') }} https://github.com/foo/bar.git:
      - root: {{ salt.grains.get('bootstrap:pillar_root', 'pillar') }}
      - env: base

Expected behavior

When a minion has bootstrap:gitfs_base set to the branch name master, both gitfs_remotes and ext_pillar will use the expected branch without any trouble.

If bootstrap:gitfs_base is set to a commit hash, then only gitf_remotes will be retrieve data and errors will be produced by pillar.

Versions Report

Observed in v3002 and v3004 when installed via debian package.

Reproduce the configuration using the shown salt template, comparing a branch name and a commit hash in gitfs_remotes and ext_pillar. Start by tracing the ext_pillar git handling for the env and revision values, then verify that a commit hash retrieves pillar data without errors while preserving the existing branch behavior.