windows git problem

windows git problem

[luis]

[-- Attachment #1: Type: text/plain, Size: 804 bytes --]

Hi Guys,

I recently run into a funny git situation.

I had a directory under git control named "someName", with a bunch of 
files inside. This was committed and working for some time.
I then added a file name "somename", and under linux, that worked OK.
However when I checked out the project under windows (either clone or 
pull) one or the other would disappear and it would be staged as removed.

The surprising bit for me was not so much that windows could not cope 
with the case sensitivity, but that git would stage the changes!

I have attached a new git project with the problem that should help show 
the issue.
If you clone from this repo on a windows box you should be able to see it

BTW, I'm using git v 1.7.4.1

-- 
Luis Gutierrez
Test and Verification Solutions (TVS)
skype: luis.tandv


[-- Attachment #2: bugdemo.tar.gz --]
[-- Type: application/x-gzip, Size: 7668 bytes --]

Re: windows git problem

[Michael Witten]

On Mon, Sep 12, 2011 at 17:35, luis <luis@tandvsolns.co.uk> wrote:
> However when I checked out the project under windows (either clone or pull)
> one or the other would disappear and it would be staged as removed.
>
> The surprising bit for me was not so much that windows could not cope with
> the case sensitivity, but that git would stage the changes!

It would be recorded in the index as a change ready to be committed
(as though `git rm' had been used)?

Re: windows git problem

[luis]

Exactly!

so the next time someone (in windows) does a commit, they remove the 
file or the folder contents!

On 12/09/11 19:05, Michael Witten wrote:
> On Mon, Sep 12, 2011 at 17:35, luis<luis@tandvsolns.co.uk>  wrote:
>> However when I checked out the project under windows (either clone or pull)
>> one or the other would disappear and it would be staged as removed.
>>
>> The surprising bit for me was not so much that windows could not cope with
>> the case sensitivity, but that git would stage the changes!
> It would be recorded in the index as a change ready to be committed
> (as though `git rm' had been used)?
>

-- 
Luis Gutierrez
Test and Verification Solutions (TVS)
skype: luis.tandv

Re: windows git problem

[Nguyen Thai Ngoc Duy]

On Tue, Sep 13, 2011 at 4:31 AM, luis <luis@tandvsolns.co.uk> wrote:
> Exactly!
>
> so the next time someone (in windows) does a commit, they remove the file or
> the folder contents!

May be this commit dc1ae70 (Support case folding for git add when
core.ignorecase=true). Forcing core.ignorecase to add_to_index() seems
a bit too strong for me. We could have added a new flag,
ADD_CASE_INSENSITIVE, to add_to_index() and enabled it only to
selected commands instead.

Or maybe we can improve the situation a little bit by warning users this case.
-- 
Duy

Re: windows git problem

[Nguyen Thai Ngoc Duy]

On Tue, Sep 13, 2011 at 8:10 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> On Tue, Sep 13, 2011 at 4:31 AM, luis <luis@tandvsolns.co.uk> wrote:
>> Exactly!
>>
>> so the next time someone (in windows) does a commit, they remove the file or
>> the folder contents!
>
> May be this commit dc1ae70 (Support case folding for git add when
> core.ignorecase=true).

I take it back. add_to_index() is mostly called by git-add. A checkout
fills the index with unpack-trees, which does not seem to be
case-insensitive to me.
-- 
Duy