In a sparse checkout scenario, the command
git checkout . restores the directories that should be ignored. Is this by design, or a potential problem in Git? I’m using
git checkout . to discard any changes I’ve made to my working copy -- is there another command that will do the same and not suffer from this problem?
Here’s a reproducible example:
rm -rf test git init test cd test for f in a b c; do mkdir $f touch $f/$f git add $f/$f git commit -m "added $f" done git config core.sparsecheckout true echo a > .git/info/sparse-checkout echo b >> .git/info/sparse-checkout git read-tree -m -u HEAD ls<blockquote>
So far, so good. Here's the problem:
git checkout . ls<blockquote>
a b c</blockquote>
By the way:
git version 18.104.22.168</blockquote>
The question <a href="https://stackoverflow.com/questions/11148579/why-do-excluded-files-keep-reappearing-in-my-git-sparse-checkout" rel="nofollow">Why do excluded files keep reappearing in my git sparse checkout?</a> is related, but much older and doesn’t quite describe what I’m seeing.Answer1:
It's not by design. The behavior has <a href="https://git.coe.so/git/commit/?id=08d595dc1cdf6f0d8e6022a69c4fcdd2fba628cf" rel="nofollow">changed</a> in <a href="http://permalink.gmane.org/gmane.comp.version-control.git/224297" rel="nofollow">Git 1.8.3</a>.Answer2:
I’m pretty sure that is by design. You are actively ordering git to create all those file, so it does that. The correct command for going back to the state of the last commit is:
git reset --hard
That should also take your sparse checkout settings into account.