Re: Possible bug with git restore

[Jeff King <peff@peff.net>]

On Thu, Aug 20, 2020 at 03:59:00PM +0300, Sergii Shkarnikov wrote:

> Here is a script to reproduce the issue that works for me in Git Bash:
> 
> =============================================
> #!/bin/bash
> 
> #create repo with corresponding structure
> mkdir restore_bug_test
> cd restore_bug_test
> mkdir incl
> mkdir src
> touch incl/test_file.hpp
> touch src/test_file.cpp
> git init
> git add .
> git commit -m"initial"
> 
> #add a couple of commits
> echo "1" >> incl/test_file.hpp
> echo "1" >> src/test_file.cpp
> git commit -am"1"
> echo "2" >> incl/test_file.hpp
> echo "2" >> src/test_file.cpp
> git commit -am"2"
> 
> #reproduce bug
> git restore -s HEAD~ -- *test_file.*
> git status
> ===============================================

That reproduces for me here on Linux, as well (for those just joining,
the interesting thing is that the final "git status" reports the files
as deleted, rather than modified back to "1").

Interestingly, if I do:

  git restore -s HEAD~ --overlay -- *test_file.*

then I get:

  error: pathspec '*test_file.*' did not match any file(s) known to git

So there are two oddities here:

  - shouldn't that wildcard pathspec match those files? I've confirmed
    that the glob characters make it into Git's pathspec machinery, and
    since it doesn't have slashes, I think we'd match a basename (and
    certainly "git ls-files *test_file.*" does what I expect).

  - even if it doesn't match, it seems weird that overlay mode would
    remove files that don't match. I'd expect it to remove files in
    trees that _did_ match the pathspec, but leave anything outside of
    the pathspec untouched.

    It's almost like we matched the pathspec in the pass over the
    working tree files, but failed to do so when reading in the tree.

-Peff