Bug report: `git restore --source --staged` deals poorly with sparse-checkout

From: Glen Choo <chooglen@google.com>
Date: Oct 3, 2022, 22:05 UTC
Message-ID: <kl6l35c4mukf.fsf@chooglen-macbookpro.roam.corp.google.com>

Filing a `git bugreport` on behalf of a user at $DAYJOB. I'm also pretty surprised by this behavior, perhaps someone who knows more could shed some light?

What did you do before the bug happened? (Steps to reproduce your issue)

  git clone git@github.com:git/git.git . &&
  git sparse-checkout set t &&
  git restore --source v2.38.0-rc1 --staged Documentation &&
  git status

What did you expect to happen? (Expected behavior)

I expected to see staged changes only, since I restored only paths outside of my sparse spec (which was t/, plus the implicit root directory).

What happened instead? (Actual behavior)

I saw a staged modification (Documentation/cmd-list.perl) and the same file reported as deleted in the working copy. Specifically,

  $ git status

  On branch master
  Your branch is up to date with 'origin/master'.

  You are in a sparse checkout with 64% of tracked files present.

  Changes to be committed:
    (use "git restore --staged <file>..." to unstage)
          modified:   Documentation/cmd-list.perl

  Changes not staged for commit:
    (use "git add/rm <file>..." to update what will be committed)
    (use "git restore <file>..." to discard changes in working directory)
          deleted:    Documentation/cmd-list.perl

What's different between what you expected and what actually happened?

git status should not have said that the file was deleted in the working copy

[System Info] git version: git version 2.37.3.998.g577e59143f-goog cpu: x86_64 no commit associated with this build sizeof-long: 8 sizeof-size_t: 8 shell-path: /bin/sh uname: Linux 5.17.11-1rodete2-amd64 #1 SMP PREEMPT Debian 5.17.11-1rodete2 (2022-06-09) x86_64 compiler info: gnuc: 12.2 libc info: glibc: 2.33 $SHELL (typically, interactive shell): /bin/bash