* Issue with sparse checkout
@ 2013-09-16 13:20 Martin Gregory
2013-09-16 22:46 ` Martin Gregory
0 siblings, 1 reply; 4+ messages in thread
From: Martin Gregory @ 2013-09-16 13:20 UTC (permalink / raw
To: git
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Issue with sparse checkout
2013-09-16 13:20 Issue with sparse checkout Martin Gregory
@ 2013-09-16 22:46 ` Martin Gregory
2013-09-17 11:27 ` Duy Nguyen
0 siblings, 1 reply; 4+ messages in thread
From: Martin Gregory @ 2013-09-16 22:46 UTC (permalink / raw
To: git
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Issue with sparse checkout
2013-09-16 22:46 ` Martin Gregory
@ 2013-09-17 11:27 ` Duy Nguyen
2013-09-17 22:16 ` re[2]: " Martin Gregory
0 siblings, 1 reply; 4+ messages in thread
From: Duy Nguyen @ 2013-09-17 11:27 UTC (permalink / raw
To: Martin Gregory; +Cc: Git Mailing List
On Tue, Sep 17, 2013 at 5:46 AM, Martin Gregory
<martin.gregory@adelaideinterim.com.au> 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
^ permalink raw reply [flat|nested] 4+ messages in thread
* re[2]: Issue with sparse checkout
2013-09-17 11:27 ` Duy Nguyen
@ 2013-09-17 22:16 ` Martin Gregory
0 siblings, 0 replies; 4+ messages in thread
From: Martin Gregory @ 2013-09-17 22:16 UTC (permalink / raw
To: Duy Nguyen; +Cc: Git Mailing List
Hi Duy,
Thanks for taking a look.
>> > 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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2013-09-17 22:18 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-09-16 13:20 Issue with sparse checkout Martin Gregory
2013-09-16 22:46 ` Martin Gregory
2013-09-17 11:27 ` Duy Nguyen
2013-09-17 22:16 ` re[2]: " Martin Gregory
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.