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
