1

I'm using git on windows. I have origin bare repository and two local repositories with the same file structure. On the firlst local repository I changed the case of a folder by renaming with `mv git Folder\file.txt folder\file.txt' and commiting the renaming. Then pushed to the origin. On the second local repository I pulled changes, however the case is not reflected. When I see logs for that file I can see that it was renamed. What could be the reasons for the changes not being reflected? Interestingly, for some other folders that I renamed the changes were reflected.

Max Koretskyi
  • 101,079
  • 60
  • 333
  • 488
  • Windows has a case-insensitive file system, it will treat files and folder with the same name but different case as if they're the same. Git has some settings that can control this, but I don't remember what they are off the top of my head. –  Mar 19 '14 at 10:00
  • They are `config.ignoreCase` :). Do you suggest that it should be `false` for the changes to be reflected? – Max Koretskyi Mar 19 '14 at 10:09

1 Answers1

2

I'm not sure it will do the trick but try

  1. Update the index with what's at the HEAD:

    git read-tree -i HEAD

  2. Remove files and/or directories which should become renamed:

    del blah
rmdir foo

  3. Force creation of the work tree files from their version at the index:

    git checkout-index -a -f

In the future be aware that Git is unfortunately does not deal well with your case. And it's understandable: on Windows, NTFS is case insensitive while case-preserving, and FATs are both case-insensitive and not case-preserving. IOW, there seems to be just no sane behaviour which Git could exhibit with regard to this issue: on one hand it should treat 'FoO/bAr.tXt' in the commit's tree and 'foo/bar.txt' on the file system to mean the same file, and on the other they should mean different things? It's not gonna work, and the only solution I could envision is some Windows-specific hack like git checkout-index --fix-work-tree-name-casing which would actually rename the work tree entities to match the index.

Update: as has been advised elsewhere, git reset --mixed HEAD can be used instead of git read-tree.

Community
  • 1
  • 1
kostix
  • 51,517
  • 14
  • 93
  • 176
  • Thanks, I'll give a try. One question - when I'll be doing that should `config.ignoreCase` be set to `true` or `false` ? – Max Koretskyi Mar 19 '14 at 13:43
  • It worked! Can you please tell me what the first command and the last do? – Max Koretskyi Mar 20 '14 at 05:39
  • 2
    When you run plain ‛git checkout‛ Git first populates the index with the files to be checked out and then syncs the work tree to it. In the general case much checks are involved in the way so my idea was: 1) force Git to have the state exactly matching the HEAD in the index, and 2) force it to re-create this state in the work tree. That's what those plumbing commands do. – kostix Mar 20 '14 at 07:10