Issue with sparse checkout

I wonder if you can advise me if this is a bug with sparsecheckout, or if not what I'm doing wrong:

http://pastebin.com/HUaWrtef

Basically, I believe that when I do git read-tree, I should be left with only
the directory CONFIGURATION.

However, DV_TDM remains.   But it's status seems to be "indeterminate" from
git's point of view - it neither reports it as being an untracked nor as being
deleted when I delete it.   FWIW, that directory contains a folder which
contains files.

I also tried a simpler sparsecheckout file, with just
/CONFIGURATION

in it, but this was worse: it left DV_SERVICES in place as well.

Thanks for any advice.

This is git 1.8.3.msysgit.0

Martin

An additional note.  I did 

git ls-files -v | grep ^S 

and I can see that the files that remain in the working version have the ^S 
bit set. 

So it does feel like a bug to me: why are files with ^S set remaining in the 
working version after 

git read-tree -mu HEAD 

?

Regards,

Martin

On Tue, Sep 17, 2013 at 5:46 AM, Martin Gregory
[off-list ref] wrote:

An additional note.  I did

git ls-files -v | grep ^S

and I can see that the files that remain in the working version have the ^S
bit set.

So it does feel like a bug to me: why are files with ^S set remaining in the
working version after

git read-tree -mu HEAD

?

I don't know. Maybe the bits are set, but then the remove operation
fails (silently). I tried to reproduce on Linux without success. It
seemed to work ok. Can you copy the (stripped down if necessary)
repository somewhere? Pack the whole thing including worktree and
config file, just in case.
-- 
Duy

Hi Duy,

Thanks for taking a look.

quoted

 > So it does feel like a bug to me: why are files with ^S set remaining in
 the
 > working version after
 >
 > git read-tree -mu HEAD
 >
 > ?

 I don't know. Maybe the bits are set, but then the remove operation
 fails (silently). I tried to reproduce on Linux without success.

I also tried to make a small repo to reproduce and failed.

I will try to strip and send ... might take a little while to get to the
point where it still happens but there's no work related stuff in there

Thanks again,

Martin