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

[Victoria Dye <vdye@github.com>]

Glen Choo wrote:
> 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 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
> 

Thanks for reporting this! There are a few confusing things going on with
'restore' here.

First is that the out-of-cone was even restored in the first place.
Theoretically, 'restore' (like 'checkout') should be limited to pathspecs
inside the sparse-checkout patterns (per the documentation of
'--ignore-skip-worktree-bits'), but 'Documentation' does not match them.
Then, there's a difference between 'restore' and 'checkout' that doesn't
seem intentional; both remove the 'SKIP_WORKTREE' flag from the file, but
only 'checkout' creates the file on-disk (therefore avoiding the "deleted"
status).

Elijah's WIP design doc [1] describes 'restore' as one of:

> commands that restore files to the working tree that match sparsity
> patterns, and remove unmodified files that don't match those patterns

albeit with other (probably related?) bugs. Given that, I think the correct
behavior would be:

1. if '--ignore-skip-worktree-bits' *is not* specified, do not restore any
   files outside of the sparse-checkout patterns.
2. if '--ignore-skip-worktree-bits' *is* specified, remove the
   'SKIP_WORKTREE' bit & check out all entries matching the pathspec to
   disk.

Fixing this should probably wait until the design doc is finalized (I've
meant to follow up on it for a while now, but I should have some time to do
that this week). In the meantime, 'checkout' will at least allow you to (for
better or for worse) avoid the "deleted" status.

Hope that helps!
- Victoria

[1] https://lore.kernel.org/git/pull.1367.v2.git.1664353951797.gitgitgadget@gmail.com/