threads / discuss / 28373

windows git problem

Subject: windows git problem

## tl;dr

5 messages between Sep 12, 2011 and Sep 13, 2011.

replies: 4people: 3as markdown or json

luis· Sep 12, 2011, 17:35 UTC · lore

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

Michael Witten· Sep 12, 2011, 18:05 UTC · re: luis · lore

Re: windows git problem

On Mon, Sep 12, 2011 at 17:35, luis <luis@tandvsolns.co.uk> wrote:

Show 5 quoted lines

> 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· Sep 12, 2011, 18:31 UTC · re: Michael Witten · lore

Re: windows git problem

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:

Show 9 quoted lines

> 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

Nguyen Thai Ngoc Duy· Sep 13, 2011, 10:10 UTC · re: luis · lore

Re: windows git problem

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

Nguyen Thai Ngoc Duy· Sep 13, 2011, 10:30 UTC · re: Nguyen Thai Ngoc Duy · lore

Re: windows git problem

On Tue, Sep 13, 2011 at 8:10 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:

Show 8 quoted lines

> 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