Question

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
a b

So far, so good. Here's the problem:

git checkout .
ls
a b c

By the way:

git --version
git version 1.7.10.4

The question Why do excluded files keep reappearing in my git sparse checkout? is related, but much older and doesn’t quite describe what I’m seeing.

Was it helpful?

Solution

It's not by design. The behavior has changed in Git 1.8.3.

OTHER TIPS

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.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top