# windows git problem 5 messages from 2011-09-12 to 2011-09-13. Participants: luis, Michael Witten, Nguyen Thai Ngoc Duy. Thread: https://gitlist.dev/t/28373 ## luis, 2011-09-12 17:35 Subject: windows git problem Message-ID: <4E6E42CE.80405@tandvsolns.co.uk> URL: https://gitlist.dev/e/4E6E42CE.80405%40tandvsolns.co.uk ``` 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, 2011-09-12 18:05 Subject: Re: windows git problem Message-ID: URL: https://gitlist.dev/e/CAMOZ1Bs6tGGJ8eZja0OaqtzK0imKt_NtiWOTgpLCaisvEXh2Rw%40mail.gmail.com In-Reply-To: <4E6E42CE.80405@tandvsolns.co.uk> ``` On Mon, Sep 12, 2011 at 17:35, luis 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, 2011-09-12 18:31 Subject: Re: windows git problem Message-ID: <4E6E5000.3040203@tandvsolns.co.uk> URL: https://gitlist.dev/e/4E6E5000.3040203%40tandvsolns.co.uk In-Reply-To: ``` 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 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, 2011-09-13 10:10 Subject: Re: windows git problem Message-ID: URL: https://gitlist.dev/e/CACsJy8B4RY4Yst9TPhNCOj8AUziFa%2BO%2B2Msen9Bt%3DQHo5SW%3DsA%40mail.gmail.com In-Reply-To: <4E6E5000.3040203@tandvsolns.co.uk> ``` On Tue, Sep 13, 2011 at 4:31 AM, luis 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, 2011-09-13 10:30 Subject: Re: windows git problem Message-ID: URL: https://gitlist.dev/e/CACsJy8Cy0nFuAVzfN9sGgd3wiQ1HE2ASW7vqY5PGt4bH4BCvtg%40mail.gmail.com In-Reply-To: ``` On Tue, Sep 13, 2011 at 8:10 PM, Nguyen Thai Ngoc Duy wrote: > On Tue, Sep 13, 2011 at 4:31 AM, luis 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 ```