Minor bug with git sparse checkout code

[Thomas Rinderknecht <thomasr@sailguy.org>]

Hello,

First, let me begin by just saying thanks to all the git developers. We switched
from cvs to git a few months ago, and it really is working well for us now that
we have overcome the initial learning curve.

We make extensive use of the sparse checkout functionality because our
repository is large and most developers don't need to see the entire source
tree. Using sparse checkout helps reduce disk usage, and also helps maintain
reasonable performance for commands such as "git status" that tend to get bogged
down when talking to slow network storage appliances.

I found what appears to be a bug in the sparse-checkout code. I am more than
happy to file a bug report on a bug tracking website, but I couldn't find one
with a quick web search. I hope that it is acceptable to post the bug report
here. Please let me know if further information is required, or if there is a
better way to file the bug report.

Short description of the problem:
---------------------------------
We have two subdirectories with similar names, for example "libs/lib1", and
"libs/lib1a". We want to check out just "libs/lib1". The sparse-checkout file
contains only a single line "libs/lib1/", but git still checks out both
subdirectories (it appears to be doing a partial match)

Sequence for reproducing the bug:
---------------------------------
(1) create a repository with similar directory names
mkdir /tmp/git_bug
cd /tmp/git_bug
git init
mkdir a1
touch a1/base
mkdir a1-extra
touch a1-extra/more
git add .
git commit -m "test"

(2) clone the repository, but don't check out the files
mkdir /tmp/git_bug2
cd /tmp/git_bug2
git clone -n /tmp/git_bug .
git config core.sparsecheckout true
echo "a1/" .git/info/sparse-checkout
git checkout
ls
<you should see that both a1 and a1_extra are checked out>

Note: We are currently using git version 1.7.2.3 ... I have not verified the bug
using the latest developmental code. Please accept my apologies if the issue has
already been addressed.

Thanks again,

Thomas R.